Zwindler's Reflection https://blog.zwindler.fr Ma vie parmi les lol-cats || je mine des bitcoins dans mon dressing Tue, 16 Jul 2019 14:08:07 +0000 fr-FR hourly 1 https://wordpress.org/?v=5.2.2 https://blog.zwindler.fr/wp-content/uploads/2017/03/nyanonimous_rond-150x150.png Zwindler's Reflection https://blog.zwindler.fr 32 32 126029280 Sortie de Proxmox VE 6.0, les nouveautés https://blog.zwindler.fr/2019/07/16/sortie-de-proxmox-ve-6-0-les-nouveautes/ https://blog.zwindler.fr/2019/07/16/sortie-de-proxmox-ve-6-0-les-nouveautes/#comments Tue, 16 Jul 2019 16:00:23 +0000 https://blog.zwindler.fr/?p=5082 Cet article Sortie de Proxmox VE 6.0, les nouveautés est apparu en premier sur Zwindler's Reflection.

]]>

Proxmox VE 6.0

Ce n’est pas la première fois que j’écris un article sur les mises à jour de Proxmox VE, une distribution Linux pour faire de la virtualisation qui me tient pas mal à cœur car très simple et très efficace. Aujourd’hui, Proxmox VE 6.0 vient de sortir !

Pour info, le blog ainsi que d’autres services fonctionnent depuis des années sur un hyperviseur Proxmox, ce qui pour moi est un exemple de stabilité et de simplicité, même dans des usecases très simples (sinon je serai passé à autre chose). M4vr0x et moi avons beaucoup écrit sur le sujet.

Mais avant ça ?

La dernière fois que j’avais écris un article sur une release de Proxmox c’était la 5.2 il y a un an, qui avait sorti pas mal de choses sympas.

Depuis, je ne vous ai pas parlé de la 5.3 et de la 5.4, quelques modifs sympas (mais que je n’ai personnellement pas utilisé).

  • Ceph Luminous LTS installable depuis la GUI (5.4)
  • Ajout d’un QDevice pour gérer le quorum dans un cluster à 2 hyperviseurs (5.4)
  • U2F dans l’interface web (5.4)
  • Nesting (faire des containers dans des containers) de containers privilégiés ou pas (5.3)
  • Emulation de VMs ARM sur hyperviseur x86_64 (5.3)

Et Proxmox VE 6.0 ???

Comme toute majeure, il faut s’attendre à pas mal de modifs.

La liste des modifications est longue comme le bras, et les ajouts sont à la fois amenés par la mise à jours des composants principaux et par des améliorations sur les composants internes.

Les composants tiers

D’abord, Proxmox VE 6.0 se base sur la toute nouvelle Debian 10.0 (aka Buster). C’est logique pour l’équipe de Proxmox de partir sur le tout dernier OS, puisque la branche 6.x va durer quelques années.

On tire donc un kernel Linux plus récent que celui PVE 5 (c’était le 4.15) et on passe sur un 5.0. De quoi tirer profit des dernières améliorations du Kernel, notamment pour le stockage (on y reviendra) et le réseau.

Ensuite, les gros composants. Proxmox VE étant une plateforme de virtualisation VM + containers, on va évidemment s’intéresser aux 2 composants qui fournissent ça, à savoir qemu et lxc ont bien évidemment droit à une mise à jour (respectivement 4.0.0 et 3.1). Pour LXC (les containers) je n’ai pas su trouver les améliorations. Pour qemu 4.0.0, on a droit à une majeure mais qui ajoute surtout la compatibilité vers de nouveaux matériels et de nouveaux flags CPU (pour des usecases bien précis).

Une plus grosse modif vient peut être de corosync, le composant qui permet de gérer une grosse partie du clustering, qui passe en version 3 avec Kronosnet. Ça, c’est très impactant. J’ai écris plusieurs articles sur le clustering de serveurs Proxmox avec des machines dédiées chez des cloud providers et j’étais souvent gêné par le fait que corosync utilise du multicast, systématiquement bloqué par les providers. Kronosnet utilise de l’unicast ce qui devrait énormément simplifier les futurs setups de clusters (AKA, plus obligatoirement besoin d’un VPN) !!!

Côté stockage, on passe de Ceph 12 vers Ceph 14 et de ZFS (on Linux) en 0.8.1 (encryption des pools + trim, support de ZFS dans l’UEFI)

Les modifs internes

Voilà pour les mises à jour de packages. Maintenant, les features que j’ai hâte de tester. La plupart sont des améliorations de la GUI :

  • Migration des VMs à chaud depuis l’interface, même si on est sur du local storage. On retrouve une promesse déjà présente en 5.x, qui marchait partiellement en ligne de commande, mais qui devrait être ENFIN disponible dans la GUI (cf ce post sur le forum).

  • Améliorations au niveau du Wizard pour créer des clusters. On peut maintenant sélectionner plus facilement quelle(s) interface(s) doit être utilisée pour la communication Corosync. Une amélioration légère par rapport à ce qu’on pouvait faire en 5.4 avec tinc (article qui n’est jamais sorti car je ne l’avais pas terminé… oups). Dans tous les cas, c’est beaucoup plus simple que ce que j’avais pu montrer en 5.2 ou en 5.0.

  • Encore des améliorations pour gérer Ceph dans la GUI. Je ne peux pas trop en parler car je n’avais pas de machines suffisament proches et puissantes pour monter un cluster Ceph sur mes machines Proxmox VE. Cependant, je pense tester dans les jours qui viennent, profitant du fait que les clusters sont plus simple à créer (donc à tester sur des machines temporaires chez Kimsufi par exemple).

  • Possibilité de configurer les backups non plus par VM/container mais par pool entier (nice to have)

Tu nous montres ?

Une fois de plus, je suis assez enthousiaste quant à cette nouvelle version, qui apporte plein de bonnes choses. Je vais très probablement faire des articles dans les semaines qui viennent sur le sujet, en premier lieu la migration de la 5.4 (sur laquelle je suis actuellement) vers la 6.0.

Wait and see !!

Sources

Cet article Sortie de Proxmox VE 6.0, les nouveautés est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/07/16/sortie-de-proxmox-ve-6-0-les-nouveautes/feed/ 5 5082
J’ai testé pour vous : l’offre Kubernetes as a service d’OVH https://blog.zwindler.fr/2019/07/09/jai-teste-pour-vous-loffre-kubernetes-as-a-service-dovh/ https://blog.zwindler.fr/2019/07/09/jai-teste-pour-vous-loffre-kubernetes-as-a-service-dovh/#comments Tue, 09 Jul 2019 11:30:50 +0000 https://blog.zwindler.fr/?p=5024 Test de l"offre Kubernetes as a Service d"OVH

Cet article J’ai testé pour vous : l’offre Kubernetes as a service d’OVH est apparu en premier sur Zwindler's Reflection.

]]>

OVH sort son offre Kubernetes managée

Vous avez peut être vu passer l’actualité début février, OVH a lancé (comme d’autres cloud providers) son offre Kubernetes as a service (KaaS).

Cette blague hilarante vous est offerte par zwindler !

Comme beaucoup de techno non triviales, une offre managée, c’est un bon moyen de mettre le pied à l’étrier si vous ne connaissez pas encore Kubernetes. C’est aussi un bon moyen pour OVH pour ne pas trop se laisser distancer par les géants américains.

En avril dernier, j’ai pu participer à un meetup dans les locaux d’OVH et de rencontrer les personnes qui avaient mis en place cette technologie. Du coup, je vous propose un petit article dans lequel on va voir ensemble à quoi ça ressemble.

Côté tarif

C’est le nerf de la guerre. Comme tous les autres (à l’exception notable d’EKS d’Amazon), vous ne payez que pour les workers, pas pour les masters (le control plane donc). Niveau tarif pour les workers, c’est simple, ce sont les tarifs applicables sur l’offre cloud public d’OVH.

La plus petite machine que vous pouvez sélectionner est un machine Linux de type B2-7, avec 2 vCPUs, 7 Go de RAM et 50 Go de SSD local.

C’est suffisant pour faire des tests, mais en production on en voudra au minimum 3, ce qui à 22€HT/mois pièce vous fera quand même environ 75€ / mois.

Au final, on est objectivement moins cher que ce que j’avais pu tester sur AKS. Car pour rappel, j’avais monté un cluster de machines de type B2ms avec 2 vCPU et 8 Go de RAM pour 30€ / mois, donc identique. SAUF que ces machines sont des machines dites "burstable" (vous n’avez qu’une portion d’un vCPU, que vous ne pouvez dépasser que pour une durée réduite avant de subir un throttling). Des machines équivalentes reviendraient sur Azure à utiliser des D2, pour un tarif de 83€TTC / mois… par machine !!!

Le fait que le control plane (les masters) ne soient pas payant est à la fois un avantage et un inconvénient. Pour OVH, je n’ai pas encore la réponse, mais lorsque j’avais testé AKS d’Azure, j’avais demandé au commercial ce qui se passait si mon control plane était HS (vu que c’est eux qui gèrent, je ne peux pas prendre la main pour le fixer). Il m’avait répondu texto : "comme c’est un produit gratuit, on ne s’engage sur aucune SLA (seulement un SLO de 2h)". De quoi refroidir quand on est habitué à avoir la main sur son cluster Kubernetes.

Et si on testait ?

Assez parlé ! Dans mon manager d’OVH, j’ai créé un nouveau projet, que j’ai nommé de manière originale "Kubernetes Project". Puis, j’ai créé un cluster Kubernetes en cliquant sur "Créer un cluster Kubernetes"

Actuellement, seul le DC "Graveline 5" semble capable d’accueillir l’offre KaaS d’OVH. Un point qu’il faudra améliorer dans le futur pour pouvoir se construire une infrastructure réellement résiliente.

Edit: Une deuxième région sera disponible dans le mois (cf Maxime Hurtrel, PM K8s chez OVH)

Niveau version de Kubernetes, bonne nouvelle, OVH s’est donné les moyens de proposer des versions très à jour de Kubernetes. Toutes les versions depuis la 1.11 jusqu’à la version 1.14 sont disponibles. La 1.14, qui n’a que quelques mois, est devenue dispo chez OVH assez rapidement. On peut imaginer que la 1.15 de Kubernetes qui vient tout juste de sortir (mi juin) sera probablement assez vite disponible aussi.

A titre de comparaison, chez Azure, ils sont assez bons dans ce domaine, et pourtant ils n’ont la 1.14 qu’en preview. Le mauvais élève Amazon est à la traîne avec seulement la 1.12 (pourtant sortie en septembre 2018).

"Ca va trop vite"

Cette partie là est relativement impressionnante. La création d’un nouveau cluster est extrêmement rapide.

Au total, l’instanciation d’un cluster met moins d’une minute, là où AKS en nécessite une 20aine (en comptant les workers certes, mais bon la moitié du temps le portal ou l’appel à l’API plante !).

Ceci est du à la façon dont le control plane a été créé et conçu par les équipes d’OVH (j’y reviendrais juste après) et est clairement une réussite. Pour avoir déployé à la main Kubernetes un paquet de fois et avec de nombreuses méthodes différentes (cf mes divers articles sur le sujet), c’est la méthode la plus rapide d’installer Kubernetes, et de loin.

L’architecture du control plane

Un des trucs sympas avec OVH, c’est qu’ils n’hésitent pas à communiquer sur les détails techniques. Certes, ils ne sont pas les seuls, mais c’est toujours agréables.

Lors du CNCF Meetup, Kevin Georges, Pierre Peronnet et Sébastien Jardin nous ont donc présenté les entrailles de leur Kubernetes as a service.

L’idée principale est que le control plane doit être le plus léger possible, pour coûter le moins cher possible à OVH (vu que c’est gratuit), tout en restant résilient.

La solution qui a été retenue pour arriver à une solution acceptable a été de déployer les services nécessaires au control plane de Kubernetes (control malanger, api server, scheduler) dans … un Kubernetes ! La seule brique non containerisée est etcd, et il s’agit ici d’un cluster dédié sur des machines physiques (ce qui explique probablement la limitation au DC Graveline).

Dans tous les cas, ça explique probablement aussi la vitesse de démarrage d’un nouveau cluster : il faut juste lancer 3 containers et zou, un nouveau cluster.

Source : OVH
https://www.ovh.com/fr/blog/kubinception-using-kubernetes-to-run-kubernetes/

L’article technique détaillant tout ça est dispo sur le site d’OVH, je n’en dis pas plus, ils l’expliquent mieux que moi.

Les workers

Pour la partie Workers, plutôt que de développer sa propre API et l’intégrer comme module du projet Kubernetes (comme les autres gros cloud providers, qui ont leur code embarqué dans celui de Kubernetes), la team chez OVH en charge du projet s’est appuyée sur de l’existant : leurs propres services OpenStack fournissent déjà l’ensemble des briques dont ils ont besoin pour créer des VMs à la volées et les intégrer à des clusters Kubernetes.

Quand j’ai demandé au Meetup combien de temps il fallait pour "poper" un nouveau worker, un des trois speakers m’a dit, tout désolé "on ne fait pas de miracles, il faut quelques minutes". Il n’a pas compris le pauvre quand j’ai éclaté de rire (parce que sur Azure, ça prend des plombes).

Ajouter des workers

La procédure est assez simple, mais se fait au travers de l’interface (comme la création du cluster). Je suis quasiment certain que tout doit pouvoir se piloter par API (je vois mal pourquoi ils auraient fait autrement pour un service tout neuf), pour autant, je n’en ai pas trouvé de trace dans la documentation officielle (pas à jour avec la nouvelle interface et encore un peu light)

Bon, alors je suis peut être mal tombé, mais quand j’ai cliqué dans l’interface pour ajouter des nodes, ça a quand même pris énormément de temps (facile 20-30 minutes). Du coup j’étais un peu (très) déçu…

Après investigation, en fait… c’est l’interface qui déconne ! En réalité, mon nœud était UP depuis longtemps déjà.

Je m’en suis rendu compte en faisant un petit kubectl get nodes et j’ai vu que mon node "Ready" depuis 28 minutes était encore marqué "En cours d’installation" …

kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
vm1.12-1 Ready <none> 28m v1.12.7 51.77.204.236 <none> Container Linux by CoreOS 2135.4.0 (Rhyolite) 4.19.50-coreos-r1 docker://18.6.3

Se connecter au cluster

D’ailleurs, comment on s’y connecte ? Pas de souci de ce côté, OVH vous simplifie la vie en vous proposant de télécharger directement votre fichier kubeconfig préconfiguré, prêt à utiliser.

Si vous en avez plusieurs, pour rappel, vous pouvez utiliser le flag "–kubeconfig=kubeconfig.yml"

En vrai, un node ne met que 3 minutes à poper

Du coup, j’ai voulu retester le démarrage d’une nouvelle VM, en sachant que le temps indiqué sur l’interface web n’est pas bon.

Après quelques tests, en 3 minutes, le node apparait en "Not Ready", puis passe "Ready" au bout de quelques secondes. On est donc très proche de ce dont j’avais pu parler avec les gens d’OVH du coup, c’est très bon comme temps de boot.

Ouf, on est rassurés !

Mise à jour

Un point sympa que permettent les solutions de type KaaS est la gestion des mises à jour depuis votre interface de gestion. Mettre à jour Kubernetes, c’est pénible. La moitié du temps, on a peur de tout casser.

Alors je ne dis pas que rien ne va casser avec le Kubernetes d’OVH, mais comme l’infra est cadrée et gérée par eux, j’imagine que c’est suffisamment bien testé dans des conditions similaires aux vôtres pour être un peu plus serein le jour où ça arrive.

A noter, contrairement à AKS, vous n’avez que peu la main sur les mises à jour. Cela se limite à ça, et je n’ai pas trouver comment monter de la 1.12 à la 1.13 par exemple…

Edit: Toujours selon Maxime Hurtrel, ça devrait arriver bientôt

Conclusion : au delà du compute, l’UI

Dans les points qui déchirent : OVH sait fournir un control plane à une vitesse à faire pâlir d’envie tous les concurrents.

Cependant, cela se fait sur un cluster Kubernetes mono DC (DC5 Graveline), avec la partie etcd externalisée à part, sur un cluster mutualisé. Je ne fais pas de jugement de valeur car, contrairement à OVH qui est transparent, je n’ai pas d’info technique sur les versions proposées par la concurrence.

En revanche, je peux comparer avec un cluster que j’installe moi même, et là clairement, je suis un cran en dessous en terme de ce qui peut être fait en terme de sécurisation de mon cluster.

Pour ce qui est de l’interface, elle souffre un peu de sa jeunesse. Il n’y a rien de plus que les onglets pour créer un cluster et pour ajouter ou supprimer des nœuds (et encore, pas plus d’info sur ces nœuds que leur nom et leur taille !).

Un dernier onglet existe pour "visualiser" ses containers et ses services, mais il est pour l’instant vide et sera de toute façon probablement moins utile que le dashboard ou tout autre outil existant (sauf à fournir un énorme effort de dev sur ce point).

Encore un exemple de la jeunesse de la solution et particulièrement de son interface : OVH pope des VMs (workers) très vite, ce qui devrait être super cool et soulever les foules… mais si on teste la solution rapidement, comme l’interface ne l’indique pas, on pourrait penser que ce n’est pas le cas ! Dommage !

Edit: Le problème est connu et en cours de fix

Et pour ce qui est des mises à jour, c’est le flou total. On vous explique que tout est maintenu à jour, mais les montées de versions majeurs sur un cluster ne semble pas disponible pour l’instant.

Dans les points pas glop : aucune trace dans la doc d’API pour créer des clusters à la volée ou les gérer de manière automatisée via Ansible ou autre…

Edit: l’API est là

Bref, vous l’aurez compris, techniquement c’est une réussite. Chez OVH, ils savent gérer des VMs et des containers et ça se voit. Mais l’offre KaaS d’OVH manque peut être encore d’un petit coup de polish pour qu’on se sente bien chez soi, et pleinement en confiance. Et c’est d’autant plus rageant que la solution a plein de bons points, que le travail abattu (en peu de temps) est colossal.

Je voudrais donc tenter de terminer sur une note positive, car c’est mon ressenti au global. Pour avoir rencontré des membres de l’équipes (de vrais passionnés), j’ai envie de croire que ce produit est amené à grandir, et ses petits défauts de jeunesse à disparaitre.

A suivre donc !

Bonus GPU

Dans les petits "trucs" qui m’ont fait sourire, j’ai vu passer un tweet indiquant qu’OVH se lançait également (en alpha par contre pour l’instant) dans Kubernetes managé avec des instances baremetal avec GPU.

Je n’ai pas forcément de workload en tête, mais pour ceux qui veulent lancer des containers avec des calculs GPU, c’est une option qui peut faire sens.

Si vous voulez en savoir plus, c’est par ici :

Cet article J’ai testé pour vous : l’offre Kubernetes as a service d’OVH est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/07/09/jai-teste-pour-vous-loffre-kubernetes-as-a-service-dovh/feed/ 5 5024
PSES 2019 : Le logiciel libre a-t-il de beaux jours devant lui ? https://blog.zwindler.fr/2019/06/27/pses-2019-le-logiciel-libre-a-t-il-de-beaux-jours-devant-lui/ https://blog.zwindler.fr/2019/06/27/pses-2019-le-logiciel-libre-a-t-il-de-beaux-jours-devant-lui/#respond Thu, 27 Jun 2019 08:30:28 +0000 https://blog.zwindler.fr/?p=5037 – De barbus dans un garage jusqu’à l’ère du « tout sur Github », comment sommes-nous passés de « Linux est un cancer » à « Microsoft <3 Linux » ?– Aujourd’hui, peut-on encore maintenir du code individuellement sans « Mettre en danger des millions d’innocents » ?– Faire de l’open source fait-il de vous […]

Cet article PSES 2019 : Le logiciel libre a-t-il de beaux jours devant lui ? est apparu en premier sur Zwindler's Reflection.

]]>

PSES 2019

Pour ceux qui ne connaissent pas, Pas Sage En Seine, c’est un festival organisé sur plusieurs jours par des passionnés, créé en 2008. Historiquement, il promouvait le hacking et le logiciel libre, mais depuis quelques années, ils fais également la part belle à toutes les activités, notamment associatives. Et cette année, les talks retenus pour PSES 2019 sont très alléchants et prometteurs (programme ici)

Cette année, je peux enfin participer. Si vous y êtes aussi, n’hésitez pas à venir me parler, de tout et de rien. Ça sera avec grand plaisir de pouvoir échanger avec des gens qui ne viennent pas forcément dans ma province ;).

J’y suis … et je suis même speaker 🙂

J’ai l’immense plaisir de donner le tout premier talk (après l’introduction par le staff) de cette édition 2019 !!!

Alors, pour vous teaser un peu de quoi je vais bien pouvoir parler, voici le pitch de mon talk :

– De barbus dans un garage jusqu’à l’ère du « tout sur Github », comment sommes-nous passés de « Linux est un cancer » à « Microsoft <3 Linux » ?– Aujourd’hui, peut-on encore maintenir du code individuellement sans « Mettre en danger des millions d’innocents » ?
– Faire de l’open source fait-il de vous un ZADiste ?

Tant de sujets d’actualité (et d’autres) qui seront traités avec un regard, bien entendu, totalement objectif et impartial (ou pas !)

Le support

J’ai promis que les slides sont en lignes, alors les voici 😉

Le live

J’espère avoir le temps de vous coller aussi le lien du live dans l’article mais je ne garantie rien 😉

La vidéo si vous n’avez pas pu venir

Et j’ajouterai bien entendu le lien vers l’enregistrement vidéo, une fois que celui ci sera disponible 😉

Cet article PSES 2019 : Le logiciel libre a-t-il de beaux jours devant lui ? est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/06/27/pses-2019-le-logiciel-libre-a-t-il-de-beaux-jours-devant-lui/feed/ 0 5037
Mes stats dans Hugo sans Google Analytics (Matomo) https://blog.zwindler.fr/2019/06/18/mes-stats-de-visites-hugo-sans-google-analytics-avec-matomo/ https://blog.zwindler.fr/2019/06/18/mes-stats-de-visites-hugo-sans-google-analytics-avec-matomo/#comments Tue, 18 Jun 2019 11:45:24 +0000 https://blog.zwindler.fr/?p=5007 Comment mettre en place Matomo pour récupérer des statistiques sur les utilisateurs avec un blog statique Hugo (CentOS + nginx)

Cet article Mes stats dans Hugo sans Google Analytics (Matomo) est apparu en premier sur Zwindler's Reflection.

]]>

Matomo, pour faire quoi ?

La semaine dernière j’ai écris un article pour expliquer que j’étais en train de migrer de WordPress vers Hugo, mais que ce n’était pas si facile. D’abord, parce que WordPress fait PLEIN de choses (et c’est à la fois son avantage et son inconvénient) et notamment vous fournir des stats sur vos visiteurs. Et, vous vous en doutez, avec un site statique, on n’a pas ça. C’est là que Matomo rentrera en jeu…

Écraser une mouche avec un bulldozer

Alors OK, les statistiques fournies par Jetpack, ce n’est pas forcément un truc fou non plus.

En réalité, on pourrait se rapprocher de ce qu’on peut faire avec WordPress en terme de statistiques avec ce que j’avais fais lorsque je testais ElasticStack et en récupérant les stats de nginx.

Mais clairement, pour en arriver au même niveau de détail, il va falloir passer pas mal de temps à nettoyer les données de références (les logs nginx) et à concevoir les tableaux de bord (dans Kibana).

Au final, on pourra même aller encore plus loin, mais ça sera nécessairement très couteux en temps de développement / configuration.

Méfie-toi du côté obscur. Plus rapide, plus facile, plus séduisant

Si c’est la simplicité que l’on cherche, alors clairement, le plus facile sera probablement d’ouvrir un compte Google Analytics et d’ajouter le petit bout de code fourni clé en main.

De ce point de vue, ça sera clairement le plus simple et vous aurez à votre disposition un outil à la fois simple et puissant. Et qu’importe si Google espionne profile (un peu plus) vos utilisateurs ?

Je vais partir du principe que si vous auto-hébergez comme moi, vous n’avez pas envie de faciliter la tâche à Google. Et c’est donc pour cela que je vous propose une autre option : Matomo.

Donc on ne sait toujours pas ce que c’est que Matomo, en fait…

Pour ceux qui l’ont connu, Matomo est le successeur de Piwik (ça vous parle peut être plus, le projet a été renommé en 2018) et permet d’obtenir un outil similaire à Google Analytics, mais open source ET que vous pouvez auto-héberger.

Exit donc, Google, pour un résultat similaire et le tout chez vous.

A noter, Matomo propose également une plateforme Analytics managée (payante), qui fera office de concurrent stricto sensu à Google Analytics et a priori plus vertueux envers la vie privée de vos utilisateurs (mais je n’ai pas vérifié).

Le usecase

J’ai donc sur les bras une plateforme Hugo pour le blog, sans aucune stat. Dans mon cas, Hugo est hébergé sur une plateforme CentOS / nginx. Idéalement, j’aimerai bien pouvoir garder mon Matomo sur la même machine, pour faire simple.

Et malheureusement pour moi, la plupart des gens qui ont fait des tutos sur le net ont eux installés ça sur Ubuntu (ça c’est respectable) et souvent sur Apache HTTPd (là par contre, emoji-qui-vomi).

Installation des prérequis

C’est donc parti pour installer Matomo dans un premier temps (on verra ensuite pour Hugo). La stack technique de Matomo étant basée sur PHP/MySQL, on va devoir installer php-fpm pour le moteur PHP et MariaDB.

Et comme sur CentOS, PHP et ses dépendances datent de Mathusalem, on va faire appel une fois de plus aux répos de rémi. Encore une fois, merci à lui…

sudo yum install epel-release
sudo yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
sudo yum install yum-utils
sudo yum-config-manager --enable remi-php72

sudo yum update
sudo yum install mariadb-server nginx php-fpm php-mysql php-mbstring php-dom php-xml php-gd freetype unzip wget

Dans le cas (probable) où vous souhaitez aussi avoir une meilleure localisation de vos lecteurs/visiteurs, il faudra ajouter des modules complémentaire pour GeoIP

sudo yum install gcc php-devel

Maintenant que c’est fait, on peut démarrer php-fpm et l’activer au démarrage de la machine

sudo systemctl start php-fpm
sudo systemctl enable php-fpm

sudo systemctl start mariadb
sudo systemctl enable mariadb

As usual, quand on installe pour la première fois mariadb (ou mysql), on n’oublie surtout pas de passer le petit tool de nettoyage/sécurisation "minimal" :

mysql_secure_installation

Ok, on a un moteur de base de données utilisable maintenant. On va donc créer une base et un utilisateur dédiés à Matomo :

mysql -u root -p
mysql> CREATE DATABASE matomo;
mysql> CREATE USER 'matomo'@'localhost' IDENTIFIED BY 'myawesomepassword';
mysql> GRANT ALL ON matomo.* TO 'matomo'@'localhost';
mysql> FLUSH PRIVILEGES;
exit

Installer Matomo

On a fait le tour des prérequis. On peut maintenant installer et commencer à configurer notre Matomo. Le plus simple reste de télécharger le dernier build sur le site de matomo, et de déposer les sources dans notre "dossier root" nginx :

cd /tmp
wget https://builds.matomo.org/matomo-latest.zip
unzip matomo-latest.zip
sudo mv matomo /usr/share/nginx/html

Dans les prérequis que vous auriez peut être loupés, Matomo conseille également d’ajouter un job de nettoyage dans la crontab. Ce n’est pas nécessaire pour démarrer, mais autant faire les choses bien dès le début. Pour faire simple, j’ai créé un fichier matomo-archive dans /etc/cron.d (mais un crontab -e ferait tout aussi bien l’affaire) :

cat /etc/cron.d/matomo-archive
MAILTO="awesome@email.provider"
5 * * * * nginx /usr/bin/php /usr/share/nginx/html/matomo/console core:archive --url=https://matomo.youdomain.fr/ > /var/log/nginx/matomo.archive.log

Ensuite, je vais partir du principe que vous allez exposer votre Matomo sur Internet, donc forcément en 443, avec une génération de certificat automatique via Let’s Encrypt.

Là c’est clairement un peu plus touchy, donc si vous voulez plus de détails sur le pourquoi du comment de chaque bloc de configuration nginx, je vous renvoie au fichier d’exemple disponible sur le github de Matomo. La subtilité par rapport au fichier d’exemple est que comme nous sommes sur CentOS et pas Ubuntu, on n’utilise pas le socket unix pour accéder à php-fpm, mais le port 9000

sudo vi /etc/nginx/sites-available/matomo.yourdomain.fr.conf

server {
  listen 443 ssl http2;
  server_name matomo.yourdomain.fr;

  ssl_certificate /etc/letsencrypt/live/matomo.yourdomain.fr/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/matomo.yourdomain.fr/privkey.pem;

  index index.php;
  root /usr/share/nginx/html/matomo;

  access_log /var/log/nginx/matomo.access.log;
  error_log /var/log/nginx/matomo.error.log;

  index index.php;

  location ~ ^/(index|matomo|piwik|js/index).php {
    include fastcgi.conf; 
    fastcgi_param HTTP_PROXY "";
    fastcgi_pass 127.0.0.1:9000;
  }

  location = /plugins/HeatmapSessionRecording/configs.php {
    include fastcgi.conf;
    fastcgi_param HTTP_PROXY "";
    fastcgi_pass 127.0.0.1:9000;
  }

  location ~* ^.+\.php$ {
    deny all;
    return 403;
  }

  location / {
    try_files $uri $uri/ =404;
  }

  location ~ /(config|tmp|core|lang) {
    deny all;
    return 403; 
  }

  location ~ /\.ht {
    deny all;
    return 403;
  }

  location ~ \.(gif|ico|jpg|png|svg|js|css|htm|html|mp3|mp4|wav|ogg|avi|ttf|eot|woff|woff2|json)$ {
    allow all;
    expires 1h;
    add_header Pragma public;
    add_header Cache-Control "public";
  }

  location ~ /(libs|vendor|plugins|misc/user) {
    deny all;
    return 403;
  }

  location ~/(.*\.md|LEGALNOTICE|LICENSE) {
    default_type text/plain;
  }
}

Maintenant que notre matomo est prêt à être accéder depuis l’extérieur, n’oubliez pas de :

  • Créer le record DNS pour matomo.yourdomain.fr
  • Générer le certificat Let’s Encrypt

Activez le site en créant un lien symbolique entre sites-enabled et sites-available, vérifiez la conf et rechargez nginx

sudo ln -s /etc/nginx/sites-available/matomo.yourdomain.fr.conf /etc/nginx/sites-enabled/matomo.yourdomain.fr.conf
nginx -t
sudo systemctl reload nginx

A partir de maintenant, le site est accessible, à l’URL https://matomo.yourdomain.fr/index.php

Editer la configuration pour forcer le TLS puis redémarrer php-fpm

vi /usr/share/nginx/html/matomo/config/config.ini.php
[General]
salt = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
trusted_hosts[] = "matomo.yourdomain.fr"
trusted_hosts[] = "blog.yourdomain.fr"
force_ssl = 1

Tuner la configuration de MariaDB pour faire plaisir à Matomo

vi /etc/my.cnf
max_allowed_packet=128M

systemctl restart mariadb

Et pour finir, cette partie manque pas mal dans la doc (genre, pas documenté du tout) et me parait pourtant essentiel. Il faut compiler les modules manquants pour ajouter GeoIP 2 (libmaxminddb et MaxMind-DB-Reader-php).

wget https://github.com/maxmind/libmaxminddb/releases/download/1.3.2/libmaxminddb-1.3.2.tar.gz
tar xzf libmaxminddb-1.3.2.tar.gz &amp;&amp; cd libmaxminddb-1.3.2
./configure
make
sudo make install
sudo ldconfig

cd ..
wget https://github.com/maxmind/MaxMind-DB-Reader-php/archive/v1.4.1.tar.gz
tar xzf v1.4.1.tar.gz &amp;&amp; cd MaxMind-DB-Reader-php-1.4.1/ext
phpize
/configure
make
sudo make install
echo "extension=maxminddb.so" > /etc/php.d/30-maxminddb.ini
systemctl restart php-fpm
Tadaaaa !

Configurer Hugo pour ajouter le code Matomo

Cool ! Tout est correctement configuré dans Matomo. Maintenant, il faut terminer par ajouter le code de Hugo pour communiquer avec Matomo.

Pour se faire, on peut utiliser le projet suivant, qui agit comme un thème complémentaire et étend le code généré par Hugo pour inclure le code de Matomo

git submodule add https://github.com/holehan/hugo-components-matomo.git themes/matomo

Dans cet exemple, j’ajoute simplement « matomo » comme 2ème thème de mon blog static dans le fichier de configuration **config.toml**

theme = ["aether", "matomo"]

Et je termine par ajouter la balise suivante dans le thème que j’utilise (ici aether, donc par exemple themes/aether/layouts/partials/head.html)

{{ partial "matomo-tracking" . }}

Vie privée

Pour que tout soit vraiment terminé, il faut également ajouter la ligne suivante dans la page dédiée à la vie privée

{{ matomo-optout }}

Et voilà le travail 🙂

Cet article Mes stats dans Hugo sans Google Analytics (Matomo) est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/06/18/mes-stats-de-visites-hugo-sans-google-analytics-avec-matomo/feed/ 3 5007
Comment migrer de WordPress à Hugo https://blog.zwindler.fr/2019/06/10/comment-migrer-de-wordpress-a-hugo/ https://blog.zwindler.fr/2019/06/10/comment-migrer-de-wordpress-a-hugo/#comments Mon, 10 Jun 2019 11:35:20 +0000 https://blog.zwindler.fr/?p=4989 Cet article Comment migrer de WordPress à Hugo est apparu en premier sur Zwindler's Reflection.

]]>

Mais c’est qui ce Hugo ?

Dans la rétrospective des 9 ans / 250ème articles sur le blog, je vous ai parlé de mes futurs projets.

Une bonne partie des projets concernent le blog lui-même, en particulier abandonner WordPress et passer à un blog statique.

Car les reproches que je fais à WordPress sont nombreux :

  • Une techno d’un autre âge, d’une lenteur infernale dès qu’on commence à avoir un peu de contenu
  • Besoin de nombreux plugins pour avoir un rendu correct pour un blog tech, pour le partage, les stats, l’antispam, les protections/firewall, des jolies balises pour les bouts de code, …
  • Des sauvegardes BDD + plugins + média à paramétrer (et complexes à tester)
  • Des caches à mettre partout pour éviter que la moindre page avec quelques images mette 5 secondes à charger…
  • Gutenberg, le nouvel éditeur qui par défaut vous fait écrire sur 550 px de large (1/5ème de mon écran, à peine plus large qu’une carte de visite)

Bref, j’en ai marre

Alors je le suis dis : pourquoi j’ai un bousin infâme qui fait le café (franchement ça fait tout et n’importe quoi WordPress, du e-commerce au CV interactif) alors que moi, j’ai juste besoin d’un bidule où je peux ecrire mes bêtises, que ça soit lisible sans avoir besoin de mettre un cache en frontal et éventuellement qu’on puisse me laisser un commentaire pour me remonter une coquille (ou juste discuter) ?

En gros, un site web statique avec un bon éditeur de texte quoi…

Les sites statiques, c’est fantastique

Alors c’est sûr, on peut aussi écrire le HTML/CSS soit même. Mais bon, avoir une application pour nous mâcher le travail et n’avoir que le contenu à gérer, c’est quand même plus sympa.

Quand j’ai commencé à m’y intéresser, un nom revenait souvent : Jekyll (et Ghost encore avant). Mais je n’ai jamais sauté le pas. Mais depuis, un petit nouveau fait parler de lui. Et comme d’autres, j’ai voulu tester Hugo pour remplacer WordPress. Hugo est un moteur de blog statique écrit en Go. Il a plutôt le vent en poupe et est assez simple à prendre en main.

C’est open source donc je peux l’auto-heberger de façon pérenne (coucou les gens qui postent une vie de travail sur Medium). Mais bien plus encore que ca, le contenu, c’est juste du Markdown. On a donc un site entièrement réversible au cas où Hugo viendrait à disparaître.

La syntaxe utilisée (Markdown, je viens de le dire) est archi connue et relativement simple à prendre en main. D’ailleurs, on peut très bien utiliser des blocs Markdown avec Jetpack dans WordPress pour écrire ses articles.

Tu te moques pas un peu de nous ?

Depuis le début, je vous dis que WordPress c’est tout moisi et que Hugo ça a l’air trop cool. Mais ce site… est encore sous WordPress !

Pour être honnête, c’était plus difficile à migrer que je le pensais, d’où cet article. A date, j’ai une copie du blog en ligne sous Hugo (EDIT : Down maintenant), qui fonctionne, mais pas totalement isopérimètre en terme de fonctionnalités. Je vais donc laisser vivre en parallèle les deux versions, le temps que je fixe tout ce qui manque.

Mais en attendant, je vous propose de me suivre pour cette merveilleuse aventure : Migrer de WordPress vers Hugo.

Installation

A en croire le site, c’est hyper simple !

C’est comme toutes les docs d’installs en page principale d’un site pour un logiciel open source, c’est simple mais en fait ça marche jamais (du premier coup). Fou cette coïncidence ! ;-P

https://gohugo.io/getting-started/installing/

Prérequis

Les prérequis sont en effet plutôt simples. Sous Debian/Ubuntu :

apt-get update
apt-get upgrade
apt-get install git python-pip

pip install Pygments

On va ensuite chercher le numéro de la dernière release sur le site https://github.com/gohugoio/hugo/releases puis on la wget + dpkg -i comme des cochons :

export VER="0.54"
wget https://github.com/gohugoio/hugo/releases/download/v${VER}.0/hugo_${VER}.0_Linux-64bit.deb
dpkg -i ./hugo_0.54.0_Linux-64bit.deb

Initialiser le site

Ok, pour l’instant, ils ne nous ont pas trop menti. Ça a l’air simple. On peut initialiser un nouveau site simplement avec la commande hugo new site. Puis ensuite, on peut versionner / sauvegarder blog et tout son contenu avec un dépôt git :

mkdir hugo &amp;&amp; cd hugo
hugo new site blog.zwindler.fr
git init

Trouver un thème

Un des soucis que j’ai avec Hugo (mais avec WordPress aussi alors je suis peut-être juste quelqu’un de pénible ?), c’est de trouver un thème.

Je veux un thème de blog (mais qu’est ce que vous avez tous à faire du e-commerce avec des moteurs de blog!!!), avec une colonne centrale assez large pour que les bouts de codes/lignes de commandes soient lisibles, avec la possibilité de mettre une image en avant sur la page d’accueil.

https://themes.gohugo.io/

Personnellement, le thème qui se rapproche le plus de ce que j’ai aujourd’hui, c’est le thème aether, auquel j’ai apporté quelques modifications. Pour ajouter un thème, le plus propre est d’utiliser la encore git, via la fonctionnalité des submodules.

cd blog.zwindler.fr
git submodule add https://github.com/josephhutch/aether.git themes/aether

Je vous donne mes modifs personnelles sur ce thème (colonne centrale plus large, modification de la taille des images sur la page d’accueil) mais cette étape n’est absolument pas nécessaire.

diff ./themes/aether/assets/css/style.css.ori ./themes/aether/assets/css/style.css
25c25
< max-width: 50rem;
---
> max-width: 60rem;
165c165
< max-width: 49rem;
---
> max-width: 59rem;
419,420c419,421
< height: 100%;
< width: 15em;
---
> height: 83%;
> padding: 1.5em 0em;
> width: 20em;

Configurer le site

Maintenant qu’on a initialisé le site et choisi un thème, on peut commencer à configurer le site et le thème. En effet, de nombreux paramètres dépendent du thème que vous aurez choisi et des fonctionnalités qu’il intègre. Je ne peux donc que vous donner un exemple :

Dans le fichier config.toml à la racine du site, voici ce qui a été paramétré

baseURL = "https://blog.zwindler.fr/"
languageCode = "fr-fr"
title = "Zwindler's Reflection"
theme = "aether"
disqusShortname = "zwindler"
[params]
brand = "Zwindler's Reflection"
description = "Ma vie parmi les lol-cats || Je mine des bitcoins dans mon garage"
homeimg = "./wp-content/uploads/2019/05/servers.jpg"

De plus, pour ajouter la coloration syntaxique sur les partions de code, il faut ajouter dans la conf les deux paramètres suivants :

pygmentsCodefences = true
pygmentsStyle = "pygments"

Puis lancer la commande suivante :

hugo gen chromastyles --style=monokai > themes/aether/assets/css/syntax.css

Extraire les données de WordPress

OK ! Notre site est paramétré. Si vous êtes sur cet article simplement pour découvrir Hugo, vous avez déjà un blog fonctionnel. Il ne reste plus qu’à écrire du contenu et générer le code statique.

cependant, dans mon cas, j’ai parlé depuis le début de migrer depuis WordPress. Je pars donc du principe que, comme moi, vous avez de nombreux articles (et éventuellement commentaires) que vous souhaitez conserver. Il serait dommage de devoir repartir de 0.

Heureusement, il est possible de récupérer les données existantes d’un WordPress pour les réimporter dans Hugo. Le site officiel liste les options possibles et notamment un plugin qui converti les articles (et éventuellement les commentaires sous les articles) en Markdown.

Tout simplement (enfin… n’exagérons rien).

wordpress-to-hugo-exporter

Je suis donc parti sur le projet wordpress-to-hugo-exporter, qui est une extension native à WordPress permettant de réaliser cet export "en un clic".

La première chose à faire pour installer cette extension est de vérifier que votre serveur qui héberge le WordPress dispose bien de l’extension PHP zip.so.

Si c’est bien le cas, on peut cloner le projet git directement dans le dossier plugin de WordPress

cat /etc/php.d/40-zip.ini
; Enable ZIP extension module
extension=zip.so

cd /var/www/html/wp-content/plugins/
git clone https://github.com/SchumacherFM/wordpress-to-hugo-exporter

Il nous faut plus de ziggourats RAM

Ça arrive tout le temps… Il n’est pas rare que les processus de ce genre (export/import/package de sauvegarde) nécessitent une grande quantité de RAM. J’avais déjà eu le souci avec Xwiki, je savais à quoi m’attendre ici.

Si vous aussi vous avez comme moi pas mal de contenu (250 articles, 500 Mo de media), sachez que vous devrez probablement augmenter les tailles mémoires autorisées par WordPress dans le fichier wp-config.php.

// Set initial default constants including WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT, WP_DEBUG, SCRIPT_DEBUG, WP_CONTENT_DIR and WP_CACHE.
wp_initial_constants();
define( 'WP_MEMORY_LIMIT', '2048M' );
define( 'WP_MAX_MEMORY_LIMIT', '2048M' );

De même, le temps que le processus d’export arrive à son terme, votre page web sera peut être partie en timeout. Deux possibilités dans ce cas.

Soit vous exécutez l’export depuis la ligne de commande

cd wp-content/plugins/wordpress-to-hugo-exporter/

This is your file!
/tmp/wp-hugo.zip

php hugo-export-cli.php
#ou pour s'affranchir des limites RAM en même temps
php hugo-export-cli.php memory_limit=-1

Dans tous les cas, vous devriez finir par obtenir un ZIP, contenant tous vos articles et toutes vos pages, au format Markdown. Le contenu de ce ZIP est à déposer dans le sous dossier content de votre arborescence de blog Hugo :

unzip wp-hugo.zip
cd hugo-export
cp -r posts wp-content ~/hugo/blog.zwindler.fr/content/

Nettoyage du markdown

Ca y est ? On peut générer le site statique maintenant ?

Et bien non… pas encore. En fait, le processus d’export de WordPress vers Markdown n’est pas parfait.

J’ai du "nettoyer" le code Markdown pour que le résultat soit enfin acceptable.

La première chose, difficilement compréhensible, est que s’il y a bien les données correspondant à l’image "mise en avant" pour chacun de nos article, le nom de la variable est featured_image alors qu’Hugo attend le nom featuredImage.

On peut régler ça avec un bête "sed"

find . -name "*.md" -exec sed -i "s/featured_image/featuredImage/g" {} \;

Par défaut, toutes les images de wordpress sont réduites dans plusieurs tailles, pour optimiser les temps de chargement. Cependant, dans l’export, on se retrouver avec des vignettes très petites, difficilement lisibles.

Pour me simplifier la vie, j’ai utilisé cette commande pour remettre les images en taille complète. Attention cependant, cela peut avoir un impact important sur les temps de chargement des pages si vous avez de très grandes images…

find . -name "*.md" -exec sed -i 's/-220x162//g' {} \;

Un des problèmes que j’ai avec l’éditeur de WordPress, c’est justement qu’il réencode tous les caractères spéciaux avec leurs codes HTML. D’un point de vue lecture de texte simple, ça ne pose souvent pas de problème. Cependant pour tout ce qui est scripts et bouts de code, ça génère très souvent des erreurs.

Voici une liste des caractères que j’ai remplacés dans mon Markdown. Attention cependant, il pourrait que cela remplace des caractères spéciaux que vous auriez légitimement (pour une raison qui m’échappe) encodé en HTML.

find . -name "*.md" -exec sed -i "s/>/>/g" {} \;
find . -name "*.md" -exec sed -i "s/</</g" {} \;
find . -name "*.md" -exec sed -i "s/&amp;/&amp;/g" {} \;
find . -name "*.md" -exec sed -ie "s/ /\n/g" {} \;
find . -name "*.md" -exec sed -i "s/–/–/g" {} \;
find . -name "*.md" -exec sed -i "s/—/—/g" {} \;
find . -name "*.md" -exec sed -i "s/…/…/g" {} \;
find . -name "*.md" -exec sed -i "s/″/″/g" {} \;
find . -name "*.md" -exec sed -i "s/′/″/g" {} \;
find . -name "*.md" -exec sed -i "s/«/«/g" {} \;
find . -name "*.md" -exec sed -i "s/»/»/g" {} \;
find . -name "*.md" -exec sed -i "s/’/’/g" {} \;
find . -name "*.md" -exec sed -i "s/‘/‘/g" {} \;

J’ai aussi trouvé les caractères suivants, que je n’ai pas osé réencoder de peur de casser des URLs :

  • &#038
  • &#039
  • &quot;
  • &#8217;

Et pour finir, dans WordPress, j’utilisais dans WordPress un plugin qui entourait mes bouts de code de balises HTML pre pour afficher du code avec la coloration syntaxique.

Dans Hugo, les balises sont celle de markdown. Voici donc la commande pour convertir les balises pre en balise de code Markdown

find . -name "*.md" -exec sed -ie "s/<pre.*>/\n\`\`\`\n/g" {} \;
find . -name "*.md" -exec sed -ie "s/<\/pre>/\n\`\`\`\n/g" {} \;

Tester le blog

Voila !!! Vous pouvez enfin tester votre blog, avec votre contenu Markdown. Hugo propose un serveur web que vous pouvez utiliser localement pour vous assurer que tout vas bien avant d’uploader votre site statique.

Il n’est évidement pas question d’utiliser ce mode en production. Il s’agit seulement d’un mode "preview".

$ hugo server

                   |  EN    
+------------------+-------+
  Pages            |  2634  
  Paginator pages  |   231  
  Non-page files   | 10951  
  Static files     |    73  
  Processed images |     0  
  Aliases          |  1187  
  Sitemaps         |     1  
  Cleaned          |     0  

Total in 7694 ms
Watching for changes in /home/zwindler/hugo/blog.zwindler.fr/{content,data,layouts,static,themes}
Watching for config changes in /home/zwindler/hugo/blog.zwindler.fr/config.toml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Sauvegarder/générer/déployer le site

Si après vérification, votre blog vous convient, vous n’avez alors plus qu’à "sauvegarder" votre site via git.

Vous pouvez ensuite générer le site statique en invoquant simplement la commande hugo

$ hugo

                   |  EN    
+------------------+-------+
  Pages            |  2634  
  Paginator pages  |   231  
  Non-page files   | 10951  
  Static files     |    73  
  Processed images |     0  
  Aliases          |  1187  
  Sitemaps         |     1  
  Cleaned          |     0  

Total in 5555 ms

Les pages statiques seront générées et sauvegardées dans le sous dossier public. Vous pourrez enfin simplement copier ce dossier sur n’importe quel serveur web (voire même des blobs sur un cloud provider) et vous aurez votre site statique !!!

Enjoy !

Cet article Comment migrer de WordPress à Hugo est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/06/10/comment-migrer-de-wordpress-a-hugo/feed/ 12 4989
Déléguer l’authentification Gitlab à Azure AD avec OAuth2 https://blog.zwindler.fr/2019/05/14/deleguer-lauthentification-gitlab-a-azure-ad-avec-oauth2/ https://blog.zwindler.fr/2019/05/14/deleguer-lauthentification-gitlab-a-azure-ad-avec-oauth2/#respond Tue, 14 May 2019 11:45:56 +0000 https://blog.zwindler.fr/?p=4961 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 […]

Cet article Déléguer l’authentification Gitlab à Azure AD avec OAuth2 est apparu en premier sur Zwindler's Reflection.

]]>
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 tierses. 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 : https://mongitlab.domain.fr/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

Cet article Déléguer l’authentification Gitlab à Azure AD avec OAuth2 est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/05/14/deleguer-lauthentification-gitlab-a-azure-ad-avec-oauth2/feed/ 0 4961
Je serai à Pas Sage En Seine pour parler logiciel libre https://blog.zwindler.fr/2019/05/07/je-serai-a-pas-sage-en-seine-pour-parler-logiciel-libre/ https://blog.zwindler.fr/2019/05/07/je-serai-a-pas-sage-en-seine-pour-parler-logiciel-libre/#respond Tue, 07 May 2019 11:45:56 +0000 https://blog.zwindler.fr/?p=4956 Pas Sage En Seine, c’est bon ! Mangez en ! Pour ceux qui ne connaissent pas, Pas Sage En Seine, c’est un festival organisé sur plusieurs jours par des passionnés, créé en 2008. Historiquement, il promouvait le hacking et le logiciel libre, mais depuis quelques années, ils fais également la part belle à toutes les […]

Cet article Je serai à Pas Sage En Seine pour parler logiciel libre est apparu en premier sur Zwindler's Reflection.

]]>
Pas Sage En Seine, c’est bon ! Mangez en !

Pour ceux qui ne connaissent pas, Pas Sage En Seine, c’est un festival organisé sur plusieurs jours par des passionnés, créé en 2008. Historiquement, il promouvait le hacking et le logiciel libre, mais depuis quelques années, ils fais également la part belle à toutes les activités, notamment associatives :

Si vous n’êtes toujours pas convaincu, sachez que le festival voit régulièrement des speakers très connus comme par exemple Stéphane Bortzmeyer, Tris Acatrinei, Laurent Chemla, Adrienne Charnet, Marc Rees (et plein d’autre encore)… mais aussi des députés Isabelle Attard et Eric Bothorel. Quand même !

Et cette année ?

Et bien le programme promet d’être tout aussi chouette que les années précédentes, avec des sujets très variés, qui dépassent largement le logiciel libre.

https://programme.passageenseine.fr/

Et si vous voulez revoir les talks des années précédentes, c’est aussi possible grâce à l’instance PeerTube de l’association.

J’ai vraiment hâte d’y être 🙂

Ça n’arrête pas

Et donc, je suis retenu en tant que speaker parmi tous ces gens :-D. Bon, je ne vais pas parler de Kubernetes comme au CNCF Meetup, ni d’Ansible comme à BDX IO 2018.

Cette fois ci (pour coller un peu au thème du festival), je vais proposer un talk sur ma vision du logiciel libre (et plus généralement du libre tout court). Voilà le pitch :

Le logiciel libre a-t-il de beaux jours devant lui ?

  • De barbus dans un garage jusqu’à l’ère du « tout sur Github », comment sommes-nous passés de « Linux est un cancer » à « Microsoft <3 Linux » ?
  • Aujourd’hui, peut-on encore maintenir du code individuellement sans « Mettre en danger des millions d’innocents » ?
  • Faire de l’open source fait-il de vous un ZADiste ?

Tant de sujets d’actualité (et d’autres) qui seront traités avec un regard, bien entendu, totalement objectif et impartial (ou pas !).

Ceux qui suivent le blog verront peut être un parallèle avec mon article « L’Open Source bashing a encore beaux jours devant lui ».

Si le sujet est le même (pourquoi le libre est mal compris et/ou dénigré aujourd’hui), l’angle sera complètement différent, sur le ton de l’humour et à grand renfort d’exemples provenant de l’actualité du libre, pour montrer qu’il reste du chemin pour promouvoir le libre, en France et dans le monde… mais on y arrivera 😉

Cet article Je serai à Pas Sage En Seine pour parler logiciel libre est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/05/07/je-serai-a-pas-sage-en-seine-pour-parler-logiciel-libre/feed/ 0 4956
Cédric O au Numérique : sexisme ordinaire ou nouveau monde ? https://blog.zwindler.fr/2019/05/04/nomination-de-cedric-o-au-numerique-nouveau-monde-ou-sexisme-ordinaire/ https://blog.zwindler.fr/2019/05/04/nomination-de-cedric-o-au-numerique-nouveau-monde-ou-sexisme-ordinaire/#respond Sat, 04 May 2019 11:45:58 +0000 https://blog.zwindler.fr/?p=4929 C’est l’histoire d’un tremplin politique Au cas où le titre de l’article n’aurait pas été suffisamment clair, il s’agit d’un billet d’humeur comme je m’en autorise rarement sur le blog… Mais sans plus attendre, rentrons dans le vif du sujet : Depuis le 31 mars (ce n’était pas une blague du 1er avril), nous avons […]

Cet article Cédric O au Numérique : sexisme ordinaire ou nouveau monde ? est apparu en premier sur Zwindler's Reflection.

]]>
C’est l’histoire d’un tremplin politique

Au cas où le titre de l’article n’aurait pas été suffisamment clair, il s’agit d’un billet d’humeur comme je m’en autorise rarement sur le blog… Mais sans plus attendre, rentrons dans le vif du sujet : Depuis le 31 mars (ce n’était pas une blague du 1er avril), nous avons appris la nomination de Cédric O comme secrétaire d’état en charge du numérique.

Note : Cet article initialement posté début mai bénéficie d’une petite mise à jour suite à un nouveau rebondissement dans « l’affaire O » 😉

Pour ceux qui n’auraient pas suivi, il succède à Mounir Mahjoubi, qui a décidé de briguer la mairie de Paris.

Mais comment s’est passé la nomination ??

En voilà une bonne question. Jusque là, donc, je n’avais pas d’avis sur cette personne. Cependant, au détour d’un tweet, voilà ce que j’apprends :

Pour ceux qui souhaitent comme moi vérifier l’article d’origine quand on lit une capture d’écran, le tweet pointe vers cet article de frenchweb.fr.

Un passage retient particulièrement l’attention :

Dans un premier temps, quatre candidates étaient pressenties : Aurélie Jean, Paula Forteza, Olivia Grégoire et Amélie de Montchalin.
Selon nos informations, un retournement de situation aurait eu lieu avec la sélection du sélectionneur par lui-même.

L’article pointe vers un autre article, qui faisait justement le portrait des 4 femmes citées plus haut, et que je vous laisse consulter si jamais vous ne les connaissez pas.

Des profils qualifiées, notamment Aurélie Jean, dont l’expérience et les qualités sont vertigineuses, sans parler de sa présence médiatique dans la Tech (pas que French, en plus).

De nombreuses personnes pensaient donc que c’était du tout cuit, par exemple le CTO et cofondateur de Blablacar, Francis Nappez, qui en parle sur LinkedIn.

D’autres voyaient plutôt Paula Forteza, dans un autre style, mais tout aussi légitime pour le poste. Avant l’annonce de la nomination, de nombreux articles allaient dans le sens de l’une ou de l’autre.

Mais pourquoi donc a-t-on préféré Cédric O, plutôt que ces femmes là ?

Tout de suite, l’idée qui vient à l’esprit est « pourquoi manquer une occasion de nommer une de ses femmes brillantes et qualifiées, pour propulser un inconnu dans le devant de la scène ? Peut être que Cédric O était un encore meilleur candidat ! »

OK. Qui est Cédric O, qu’a-t-il fait avant ?

Un rapide tour sur Wikipedia permet d’apprendre qu’il est diplômé d’HEC. Un vrai expert du numérique de formation, donc. Pour info/rappel, Mounir Mahjoubi sortait de Sience Po, donc au final, les cyniques diront que ça ne change pas grand chose.

Ensuite, il s’est engagé en politique avec d’autres proches du président (dont certains qui ont fait parler d’eux récemment, dont Ismaël Emelien) à l’époque DSK, puis chez En Marche, où il a été trésorier. Là encore, un poste idéal pour un futur secrétaire d’état chargé du numérique.

Quel rapport avec le numérique ?

Il suffit de taper « Cédric O » et « geek » dans votre moteur de recherche préféré pour voir la flopée d’articles qui sont sortis sur lui (tous pompés les uns sur les autres) depuis. On essaye donc de nous faire croire qu’il est qualifié pour le poste car… c’est un geek.

Un peu comme quand Mounir Mahjoubi nous expliquait qu’il avait passé son adolescence sur IRC. Ça nous fait une belle jambe.

Alors d’accord… je suis très critique alors qu’il fera peut être très bien le job.

Mais bon … Quelle occasion gâchée d’avoir au numérique des femmes charismatiques, qui savent de quoi elles parlent, pouvant servir de « role model » pour des jeunes filles, alors qu’on sait qu’elles se détournent toujours plus du numérique. Ça me rappelle cruellement le talk d’ouverture de BDX.IO 2018 d’Audrey Neveu – The Hitchhiker’s Guide to Diversity (Don’t panic!).

Je note d’ailleurs la réaction assez molle de toute la classe politique et tous les « experts » qui peuplent la twittosphère et qui étaient bien plus inspirés par la nomination de Sibeth Ndiaye (mais c’est une autre histoire). Hormis le tweet que j’ai cité en début d’article, pas ou peu de réaction.

Cédric O a une sœur

Pour finir et faire écho à mon titre, s’agit-il de sexisme ordinaire comme le sous-entend le tweet de CodeForFR, ou y a-t-il une autre raison ?

La raison qui fait de Cédric O un candidat plus désirable que toutes ces femmes dont on parle depuis le début, se trouve peut être en dernière ligne de cet article de NextInpact :

Mounir Mahjoubi va maintenant retrouver son poste de député, récupérant le siège qu’il avait laissé à sa suppléante, Delphine O, sœur de Cédric O.

Source : https://www.nextinpact.com/brief/cedric-o–nouveau-secretaire-d-etat-charge-du-numerique-8288.htm?skipua=1

Mise à jour du 03/06/2019

Et quelle n’a pas été ma stupéfaction d’apprendre, par tweet interposé, que Delphine O avait également eu son lot de consolation pour bons et loyaux services dans le nouveau monde :

Permettez donc moi un petit moment de fiction de mon propre cru, sur ce que je pense qu’il s’est passé, fin mars.

Allo, Delphine ? Désolé, je suis plus ministre… Ben… du coup, ça veut dire que je reprend mon siège… Ouais je sais, c’est pas cool.
Mais ne t’inquiètes pas, en échange, je pousse ton frère comme mon remplaçant. Et puis toi, on te trouves un poste sympa, comme ambassadrice. Comme ça on est quittes.

#NouveauMonde, je vous le disais…

Cet article Cédric O au Numérique : sexisme ordinaire ou nouveau monde ? est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/05/04/nomination-de-cedric-o-au-numerique-nouveau-monde-ou-sexisme-ordinaire/feed/ 0 4929
Suivez le lapin Orange – Intro et bonnes pratiques d’infra RabbitMQ https://blog.zwindler.fr/2019/04/16/suivez-le-lapin-orange-intro-et-bonnes-pratiques-dinfra-rabbitmq/ https://blog.zwindler.fr/2019/04/16/suivez-le-lapin-orange-intro-et-bonnes-pratiques-dinfra-rabbitmq/#comments Tue, 16 Apr 2019 11:45:07 +0000 https://blog.zwindler.fr/?p=4924 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 […]

Cet article Suivez le lapin Orange – Intro et bonnes pratiques d’infra RabbitMQ est apparu en premier sur Zwindler's Reflection.

]]>
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 ;).

Cet article Suivez le lapin Orange – Intro et bonnes pratiques d’infra RabbitMQ est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/04/16/suivez-le-lapin-orange-intro-et-bonnes-pratiques-dinfra-rabbitmq/feed/ 2 4924
J’ai testé pour vous Shadow, la plateforme FR de cloudgaming https://blog.zwindler.fr/2019/04/02/jai-teste-pour-vous-shadow-la-plateforme-fr-de-cloudgaming/ https://blog.zwindler.fr/2019/04/02/jai-teste-pour-vous-shadow-la-plateforme-fr-de-cloudgaming/#comments Tue, 02 Apr 2019 11:45:27 +0000 https://blog.zwindler.fr/?p=4881 Note : Il ne s’agit pas d’un article sponsorisé. Pour être honnête, j’avais des questions techniques et Shadow/Blade a même refusé de me répondre ;-p. Vous pouvez donc lire cet article sans craindre que j’aie été influencé. Mais pourquoi tu nous parles de Cloud Gaming ?? A l’heure où tout le monde s’extasie (ou pas) […]

Cet article J’ai testé pour vous Shadow, la plateforme FR de cloudgaming est apparu en premier sur Zwindler's Reflection.

]]>
Note : Il ne s’agit pas d’un article sponsorisé. Pour être honnête, j’avais des questions techniques et Shadow/Blade a même refusé de me répondre ;-p. Vous pouvez donc lire cet article sans craindre que j’aie été influencé.

Mais pourquoi tu nous parles de Cloud Gaming ??

A l’heure où tout le monde s’extasie (ou pas) suite à l’annonce de Stadia de Google, je prend le contre-pied de (quasiment) tout le monde et je vais vous parler un peu de Shadow de la société Blade, la plateforme de cloud Gaming à la française !

En fait, ce sujet m’intéresse depuis le début du blog et mes premières bidouilles en 2010. Un des objectifs que je m’étais fixé était de pouvoir avoir une plateforme mutualisant à la fois mon serveur avec ses VMs ainsi qu’une plateforme de jeu, dans une même boite. L’idée était d’avoir juste un écran/clavier/souris ou un portable, n’importe où dans la maison, et de déporter le bruit et la chaleur dans une pièce, plus loin.

A l’époque, j’avais monté une plateforme de virtualisation, idéale pour le serveur, mais pas trop pour une plateforme de gaming déportée. Dans les soucis que j’avais rencontré, la partie virtualisation de GPU et/ou GPU paththrough était un peu capricieuse, et surtout, le plus gros souci de l’époque, étaient les protocoles de streaming.

Clairement, on n’avait pas ce qu’il fallait pour streamer efficacement et facilement un jeu, même en LAN (malgré quelques avancées chez Citrix et Microsoft avec 2008r2).

Un peu plus tard, le streaming by Steam et NVidia

Quelques années après, Steam a carrément cassé la baraque en apportant la possibilité de streamer des jeux d’un PC à un autre dans la maison. Sur un LAN Ethernet, les contrôles sont fluides, l’image aussi, et j’ai rencontré très peu de bugs. Côté streaming, c’était clairement gagné. On peut aussi noter le NVidia Shield, qui apporte une expérience similaire, mais qui nécessite d’acheter le produit (c’est pour ça que je ne l’ai jamais testé, mais ça marche bien a priori).

Mais il me manquait encore un petit quelque chose. J’avais encore besoin d’avoir un PC séparé pour le jeu et un autre pour les machines virtuelles, ne sachant toujours pas comment mutualiser le jeu et la virtu (voire de virtualiser le GPU dans une VM).

Et vint Shadow

Clairement, j’avais laissé de côté cet objectif. Et puis, au fil du temps, est arrivé fin 2017 Blade, avec son service Shadow. La promesse, alléchante, était : avoir un PC gamer haut de gamme, évolutif au fil des années, sans avoir à acheter/installer du matériel haut de gamme.

Plus besoin de hardware : ton Shadow tient dans une simple application. Un PC complet avec des performances haut de gamme, accessible sur tous tes écrans, en un clic.

Comme nous prenons en charge le hardware, ton Shadow n’est jamais obsolète. Processeur, carte graphique, mémoire… Ta configuration est mise à jour régulièrement

Si on regarde la fiche technique telle qu’elle est disponible aujourd’hui (https://shadow.tech/discover/specs), pour ~30€ par mois avec une offre d’engagement, on peut avoir une machine avec une GTX 1080, 8 threads dédiés (Xeon), 12 Go de DDR4 et 256 Go de stockage SSD. Shadow s’adresse donc bien, a première vue, à un public gamer relativement haut de gamme.

2ème point important, si Shadow -et plus généralement le cloud gaming- ont un peu de mal à percer, c’est notamment car de nombreuses personnes n’avaient pas de connexion suffisament stable, avec une faible latence et un débit suffisant pour jouer dans de bonnes conditions.

Si sur de la diffusion type IP-TV, on peut se contenter d’un flux avec un peu de différé pour absorber la latence et la gigue, voire pour optimiser la bande passante, et ainsi permettre à ceux qui ont peu de débit d’en profiter.

Ce n’est évidemment pas possible pour un jeu vidéo, où l’expérience utilisateur sera dégradée, même pour le moins exigeant des gamers, dès ~50 ms (et bien moins pour les plus exigeants).

Avec une latence souvent inférieure, beaucoup plus stable, et des débits très largement suffisant pour passer un flux vidéo même peu compressé, la fibre semble donc être un prérequis (on y reviendra) à Shadow.

Comparer ce qui est comparable

Maintenant que c’est dit, revenons à mon expérience Shadow, par rapport à mon expérience de jeu habituelle.

Et ça tombe super bien, parce que c’est à peu de choses près la configuration Gamer que j’ai chez moi également (i7 gen4, GTX 1080, 16 Go de RAM, SSD). On est donc sur des machines comparables sur le papier.

En réalité, il y a probablement de grosses différences entre une machine bien ventilée et dédiée sous son bureau et une VM (ou une machine physique ?) avec un GPU dans un rack, et qui accède à une baie de disque SSD partagée par des centaines de personnes.

Crédits : Blade

Pour finir, la raison qui m’a vraiment décidé à tester récemment, c’est parce que j’ai enfin la fibre chez moi ! A moi les connexions rapides et stables (ENFIN!).

Économiquement, est ce que ça tient la route ?

Je ne suis (vraiment) pas le premier à tester Shadow (je vous ai laissé en fin d’article une petite compilation des blogs que j’ai lus avant de me décider de tester le service), mais un point que je n’ai vu dans aucun article, c’est l’analyse du prix.

Cette analyse est très difficile à faire car elle dépend de beaucoup de facteurs subjectifs, notamment sur la durée de vie et d’amortissement du matériel. Pour certains, un GPU ne dure pas plus d’un an quand d’autre le garderont jusqu’à ce qu’il tombe en panne ou soit réellement obsolète dans 10 ans. On peut aussi compliquer le problème en partant du principe que le matériel vieillissant peut être revendu !

Je suis donc parti sur les hypothèses suivantes :

  • J’ai profité d’une promotion pour Shadow à 30€/mois sans engagement. Cependant, vous pouvez obtenir un prix similaire hors promo en vous engageant sur 1 an
  • J’ai estimé le prix des composants de mon PC (similaire à Shadow en terme de caractéristiques) au moment où je les ai acheté
  • Je garde mes composants environ 5 ans, sauf le boîtier et le ventirad (10 ans), après quoi je considère que leur valeur résiduelle est négligeable (ils peuvent même être tombés en panne et remplacés hors garanti AVANT les 5 ans)
  • Ça peut paraître anecdotique, mais avec Shadow, vous allez faire des économies d’électricité, puisque vous pouvez vous contenter d’un PC basse consommation. J’ai donc estimé la consommation électrique de ma machine de guerre et j’ai multiplié cette quantité d’électricité par 4h de jeu / semaine

Voilà le détail du calcul :

Avec MES hypothèses, on tombe donc sur un prix sur 5 ans relativement similaire à l’achat d’une machine montée soit même, avec les composants achetés à l’unité et durant 5 ans.

D’un point de vue purement économique, la bonne nouvelle est donc que Shadow est totalement pertinent par rapport à l’achat d’un PC haut de gamme..

Qualité vidéo

Maintenant que c’est dit, on peut s’attaquer au ressenti utilisateur, en commençant par la qualité du flux vidéo.

Comme je l’ai dis plus haut, contrairement à de la TV sur IP, le stream de jeu doit être le plus rapide et fluide possible. On ne peut pas perdre trop de temps à compresser de manière optimale le flux. Cela induit donc des protocoles nécessitant peu de calculs (et donc potentiellement moins perfectionnés) et des bandes passantes importantes.

Ça va être difficile de vous « montrer » la différence entre l’image réelle et l’image affichée sur mon écran. Je ne vais pouvoir parler que de ressenti.

 

Mon ressenti (personnel donc), quand j’ai lancé pour la première fois Shadow, est une image un peu baveuse; ce n’est pas aussi net qu’en local.

Mais ce n’est qu’une impression, car en regardant en détail, je n’ai rien pu déceler de visible, en me concentrant sur une partie de l’écran par exemple. Les caractères paraissent nets, il n’y a pas d’artefacts liés à une compression (comme quand on compresse trop un JPG par exemple).

Mais dès la première heure de jeu, je ne le voyais plus. A un tel point, que je me suis finalement dis que j’avais du me tromper, que c’était un biais cognitif… jusqu’à ce que j’arrête d’utiliser le Shadow !

Dès que je suis retourné jouer exclusivement sur mon PC, j’ai tout de suite senti une image plus nette, sans réussir à expliquer pourquoi.

Je précise que je joue sur un 29 pouces extra large (21:9ème) en 2560*1080. Je ne peux donc pas dire quel impact cela a par rapport à une configuration plus classique en 16:9ème (qu’on soit en Full HD ou plus). Certaines personnes avec des résolutions plus élevées (et donc plus rares) ont eu des retours plus ou moins positifs.

Cette résolution n’a posé aucun problème (parfois le cas sur des protocoles de streaming/prise en main à distance).

Bande passante

La première chose à faire lorsqu’on lance le client Shadow sur un nouveau device est de lancer un test de connexion.

Grosso modo, vous pouvez fixer une bande passante maximale, jusqu’à 50 Mb/s, ou choisir le test de connexion, qui vous permettra, le cas échéant, d’avoir jusqu’à 70 Mb/s (mon cas).

Récemment, Blade a communiqué sur une nouvelle fonctionnalité du Shadow => la possibilité d’utiliser le protocole H.265 sur des machines récentes (capable de le décoder nativement), pour réduire la bande passante et ainsi permettre aux gens disposant d’une connexion ADSL/VDSL de bonne qualité d’en profiter.

Dans l’interface Shadow, il est question d’un « Mode faible connexion ».

Je trouve cette terminologie étonnante. sur le papier, le protocole H.265 est très probablement un bon protocole, AUSSI pour les bonnes connexions.

Pour autant, effectivement, en faisant des tests, je n’ai pas trouvé d’amélioration à passer sur ce protocole, voire même des dégradations dans la netteté (là encore, c’est du ressenti).

Le point le plus visible que je peux vous montrer, sont les caractères sur fonds blancs dans l’explorateur Windows autours desquels ont peut déceler un léger halo rouge :

En plus de ça, en consultant les stats, je n’ai pas remarqué un réel gain en terme de bande passante par rapport au protocole standard….

Je ne me l’explique pas vraiment, mais cela explique très certainement pourquoi Shadow ne le met pas en avant, avec cette dénomination que je trouve un peu « péjorative ». A voir si ça s’améliore dans le futur.

Réactivité des contrôles, latence

C’est là où je m’attendais à un gros flop et j’ai vraiment été bluffé. Avec une latence entre chez moi (Bordeaux) et les datacenters de Blade (hébergés par Equinix, près de Paris) à 20 ms (très stable), je m’attendais à être capable de déceler un lag, notamment sur les jeux multijoueurs.

Crédits: Blade

En réalité, après avoir joué en ligne à Star Wars Battlefront 2, une partie de la latence induite par l’aller-retour entre chez moi <=> DC de Blade est probablement compensée par le fait que les serveurs de jeu sont plus près. Le tout étant masqué par le « netcode », je n’ai ABSOLUMENT pas vu d’impact sur le jeu, même en FPS/multijoueur.

Les plus hardcores d’entre vous qui cherchent le moindre ms pour sniper dans CS:GO ou qui vivent dans un datacenter seront bien entendu vent debout contre cette affirmation. Cependant, dans mes conditions de jeu, à mon échelle de semi-casual vivant en province, je n’ai pas réussi à voir de différence ! C’est vraiment bluffant.

Autres configurations du client

Au delà du protocole vidéo, le client Shadow propose un grand nombre d’options et de fonctionnalités (expérimentales, ou pas), c’est très agréables. Je ne les ai d’ailleurs pas toutes essayées.

Un des gros points gênant pour Shadow -jusqu’à il y a peu- était le fait qu’il n’y avait pas moyen de passer le son du microphone quand vous aviez un micro-casque jack. C’est normalement corrigé, comme vous pouvez le voir, avec le support Expérimental de l’option.

Personnellement, ayant plusieurs plusieurs périphériques USB (micro-casque, contrôleurs, …), la fonctionnalité de « forwarding USB » a parfaitement fonctionné. Aucun bug à remonter.

Et sur d’autres écrans ?

Dans sa publicité pour Shadow, Blade met en avant le fait qu’on peut jouer n’importe où. Sur le papier, l’idée séduit, une fois de plus : c’est tout l’avantage du cloud, plus besoin d’amener sa tour en déplacement, un simple PC portable suffi(rai)t.

Dans la pratique, ce n’est évidemment pas si facile. S’il existe une application Apple et Android, je vois mal qui jouerait un jeu PC sur un iPad, encore moins sur un smartphone. En terme d’ergonomie, utiliser un PC sur une tablette à toujours été un peu fantaisiste, encore plus dans un contexte du jeu.

Quant au PC portable, il va falloir avec :

  • 1) Une bonne connexion sur le lieu où vous voulez accéder à Shadow. On en revient toujours au même => pas de Fibre = risques de problèmes à prévoir
  • 2) Attention à la connectivité Wifi ! J’ai eu une expérience catastrophique (injouable) avec le wifi (N) de ma Freebox v6. Le wifi AC est d’ailleurs fortement conseillé par Blade si vous n’avez pas le choix. Gardez en tête que c’est quasiment ethernet (sans CPL si possible) ou rien si vous voulez éviter de vous faire peur.

Avec ces 2 contraintes, ça limite donc grandement les lieux éligibles à l’accès à votre plateforme Shadow en mobilité…

Au delà du jeu

Un point qu’on oublie quand on compare Shadow aux autres offres de cloud gaming est le fait que Shadow est une VM dédiée dans le cloud.

C’est VOTRE Windows. Rien ne vous empêche donc de l’utiliser pour autre chose que jouer.

Vue la puissance du bouzin, vous pourriez très bien héberger des serveurs quand vous ne jouez pas. Pour autant, j’ai du mal à voir le cas d’usage, puisque la machine est éteinte quand vous ne l’utilisez pas…

Autre idée, on pourrait en faire une plateforme de téléchargement pour de gros fichiers. Je vous voit arriver avec vos gros sabots (et Blade aussi) => dans une interview, il était questions de surveiller les trafic upload/download anormaux par rapport à la charge. Mais dans tous les cas, vu le prix, on ne peut pas dire que Shadow soit une offre idéale pour faire une seedbox…

Conclusion

Je me suis déjà beaucoup étalé sur Shadow, et je trouve que c’est un produit super. Vient donc le temps d’arrêter d’en rajouter et de faire un petit résumé.

Techniquement, Shadow est un produit qui fonctionne, à un tarif cohérent. Le pari de fournir une machine dans le cloud pour remplacer un PC coûteux est tenu, dans certaines limites.

  • Les joueurs les plus acharnés trouveront que la latence ou la (très légère) dégradation de l’image n’est pas acceptable
  • Beaucoup d’utilisateurs se plaignent des performances du stockage, certes sur des baies SSD, mais probablement trop sollicité par rapport au nombre d’utilisateurs
  • La promesse de pouvoir jouer partout est purement marketing // sans connexion fibre (ou VDSL très stable) et full Ethernet, point de cloud gaming ; c’est la vie
  • Ça fait un bon moment que le Shadow fonctionne avec une GTX 1080. Difficile de tenir la promesse « d’un PC toujours à jour » quand NVidia sort des GPU aussi cher que les RTX…

Personnellement, quand j’ai démarré l’abonnement, au vue du prix et des fonctionnalités proposées, je me suis réellement posé la question d’abandonner mon PC fixe et de ne garder que Shadow. Mon objectif était de vendre ma tour et de jouer sur mon portable, via Shadow.

Après un mois d’utilisation, j’ai résilié l’abonnement. Cependant, j’insiste : ce n’est pas parce que Shadow est un mauvais produit. Shadow est un produit abouti et stable.

Cependant, il ne faut pas non plus se voiler la face, Shadow n’est pas à la hauteur d’une machine physique avec un i7 et une GTX sous votre bureau.

En revanche, si demain, mon PC tombe en panne, la question se reposera (très sérieusement). Mais en l’état, je préfère garder ma machine de guerre ;).

Lectures complémentaires

Cet article J’ai testé pour vous Shadow, la plateforme FR de cloudgaming est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/04/02/jai-teste-pour-vous-shadow-la-plateforme-fr-de-cloudgaming/feed/ 4 4881