Zwindler's Reflection https://blog.zwindler.fr Ma vie parmi les lol-cats || je mine des bitcoins dans mon dressing Thu, 28 Nov 2019 15:00:31 +0100 fr-FR hourly 1 https://wordpress.org/?v=5.3 https://blog.zwindler.fr/wp-content/uploads/2017/03/nyanonimous_rond-150x150.png Zwindler's Reflection https://blog.zwindler.fr 32 32 126029280 [Humeur]Ces gens qui amènent leur bébé au bureau pour poster leurs aventures sur LinkedIn https://blog.zwindler.fr/2019/11/26/humeurces-gens-qui-amenent-leur-bebe-au-bureau-pour-poster-leurs-aventures-sur-linkedin/ https://blog.zwindler.fr/2019/11/26/humeurces-gens-qui-amenent-leur-bebe-au-bureau-pour-poster-leurs-aventures-sur-linkedin/#comments Tue, 26 Nov 2019 07:14:15 +0000 https://blog.zwindler.fr/?p=5211 Billet d'humeur sur ces gens qui amènent leur bébé au bureau pour poster ensuite leurs aventures sur LinkedIn

Cet article [Humeur]Ces gens qui amènent leur bébé au bureau pour poster leurs aventures sur LinkedIn est apparu en premier sur Zwindler's Reflection.

]]>

Comme tout le monde, j’ai ma vision de la vie. Parfois, j’ai du mal à comprendre la vision des autres.

Je rage un bon coup, puis je me rappelle qu’on est tous différents, je me dis que c’est juste parce que je suis un jeune imbécile ou au contraire déjà un vieux réac, je rigole de moi-même et je passe à autre chose.

Mais depuis peu, il y a un truc que je capte pas, mais alors pas du tout.

"Je suis profondément choqué !"

LinkedIn, on y trouve de tout. Et des fois c’est vraiment la lie de l’humanité. Pire que Facebook ou Twitter.

Ce n’est pas pour rien que le compte Disruptive Humans of LinkedIn compte autant d’abonné. LinkedIn, malgré toutes les qualités que je lui trouve, c’est parfois un puit sans fond d’imbécilités.

Du grand classique sur LinkedIn…

Ca fait quelques fois, depuis moins d’un an je dirais, que je vois passer des posts de papas, fiers comme des coqs, avec leur bébé au travail. Note: Je ne parle pas d’un enfant, mais bien de bébés (<1ans).

Ici, c’est un papa qui n’a "pas de solution pour garder son enfant l’été, et qui est trop content d’avoir un patron compréhensif qui lui permet d’amener son bébé au travail"

Là, un papa qui appelle son manager pour lui dire qu’il ne viendra pas, car son fils est malade. Qu’à cela ne tienne lui rétorque son Manager 4.0 "Mais ramène le au bureau ! Ca nous fera de l’animation !" (Verbatim). Et de surenchérir le post d’un "merci chef tu es le meilleur des chefs". Et les patrons de congratuler leur bon soldat, assurément un papa 4.0 modèle.

Mais qu’est-ce que ça peut faire ?

Je vais volontairement passer sur le fait que je suis totalement opposé à l’exposition des enfants, surtout si petits, aux réseaux sociaux (je vous renvoie au point "vieux reac/jeune imbécile"). C’est hors sujet ici. Car franchement je suis scié par tout le reste.

Mais dans quel monde vivent ces gens ?

A quel moment, tu te dis que ça va être une bonne idée d’amener pendant tout le mois de juillet ton bébé au bureau ?

Que tu vas laisser sécher comme un raisin sec dans son transat, posé au dessus de ton bureau en trophée (car oui, c’est ça la photo mise en avant par l’auteur). A quel moment un parent peut trouver ça désirable, voire même ne serait ce qu’acceptable, comme solution ?

Et le deuxième exemple… que dire ! Un enfant malade, qui a besoin de calme, de repos et d’amour pour récupérer… l’amener au bureau, sur l’idée du patron, parce que ça va faire "de l’animation" ?

Pourquoi ? C’est une bête de foire ton gamin quand il a 38.5 ?

Et une fois que tu y seras, tu crois que tu vas avoir la tête à bosser ?

Non non non non ! Surtout ne répond pas, j’ai trop peur que tu me répondes "oui".

C’est pas facile d’être parent

C’est pas facile d’être président

François Hollande, quand il était encore président

Alors je veux bien essayer d’être compréhensif. Peut-être que ces personnes n’avaient vraiment aucune autre solution ?

Avoir un enfant, c’est compliqué et ça demande parfois des sacrifices. Et parfois, il faut trouver une solution, même si elle n’est pas optimale.

Mais pitié, n’en faites pas un post sur LinkedIn !

Ne faites pas comme si c’était un modèle de modernité à suivre !

Aussi bien vous, employés, que vous, "gentils patrons" qui les poussent ou les autorisent à ce genre d’actions débiles.

Et le pire dans tout ça.

Le pire dans tout ça, c’est que personne sur le réseau social ne trouve rien à y redire.

Les gens likent, applaudissent des deux mains, commentent pour porter aux nues ces papas résolument modernes (sic). Les rares commentaires négatifs sont juste des gens qui râlent que l’employé risque de ne pas bien travailler.

Et pour l’enfant ? Rien ? Personne ?

Du coup, j’en viens à me demander s’il n’y a que moi qui trouve ça anormal, même malsain. Je dois être bizarre…

Mais, franchement, là, ça me dépasse.

Sources

Bonus DHoL "Bienvenue dans mon réseau"

Cet article [Humeur]Ces gens qui amènent leur bébé au bureau pour poster leurs aventures sur LinkedIn est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/11/26/humeurces-gens-qui-amenent-leur-bebe-au-bureau-pour-poster-leurs-aventures-sur-linkedin/feed/ 2 5211
Changement de provider, mon hyperviseur sur un dédié Hetzner https://blog.zwindler.fr/2019/11/19/changement-de-provider-mon-hyperviseur-sur-un-dedie-hetzner/ https://blog.zwindler.fr/2019/11/19/changement-de-provider-mon-hyperviseur-sur-un-dedie-hetzner/#comments Tue, 19 Nov 2019 07:30:00 +0000 https://blog.zwindler.fr/?p=5225 Suite à des soucis avec le support de OneProvider, j'ai décidé de migrer une partie de mes serveurs vers le provider Hetzner

Cet article Changement de provider, mon hyperviseur sur un dédié Hetzner est apparu en premier sur Zwindler's Reflection.

]]>

Au revoir OneProvider, bonjour Hetzner

Certains d’entre vous m’ont peut être vu me plaindre de OneProvider et plus particulièrement le support avec qui j’ai eu plusieurs accrochages (Spoiler, j’ai migré vers Hetzner).

Sans rentrer dans les détails (j’ai échangé avec certains d’entre vous sur le sujet), après cette déconvenue, j’ai donc cherché une alternative pour héberger mes machines.

Les prérequis étaient d’avoir :

  • une machine physique
  • avec suffisamment de RAM (minimum 8 Go, 16 c’est mieux)
  • idéalement, une gestion des réseaux virtuels entre machines du provider (type RPN ou vRack)
  • si possible pas un ATOM en CPU (le souci de l’ATOM, c’est que c’est tellement faiblard que ça pénalise les IO)
  • si possible du VT-x (je n’en ai pas besoin d’en l’absolu, je vais surtout du LXC, mais ça peut dépanner)
  • si possible du SSD parce que c’est quand même cool
  • si possible 2 disques pour avoir du RAID ou que je puisse me faire un équivalent (ZFS/ZRAID)
  • un prix pas trop élevé (genre pas OVH) car j’ai été mal habitué avec les prix agressifs de OneProvider (oui je sais, je l’ai payé avec le support)

L’état du marché

Chez OneProvider, j’avais tout ça pour environ 20-25 euros / mois, à l’exception du réseaux privé virtuel entre machine.

Autant dire qu’on est très loin du premier prix de chez OVH (>60€/mois TTC). Si on descend en gamme chez OVH, on perd le réseau privé virtuel entre machines (vRack) en passant chez SoYouStart et pourtant on est toujours à plus de 42€ / mois TTC. Toujours 2 fois plus cher que OneProvider :-/.

Il faut descendre encore de gamme et passer chez Kimsufi pour trouver des prix comparables dans mes critères (et toujours pas de réseau privé virtuel), avec de vieux CPU et surtout un réseau bridé au 100 Mbps (ce qui est pénible pour les transferts de gros fichiers, les réplications de VMs et les sauvegardes).

J’avais aussi jeté un œil côté Online.net, qui eux proposent sur certaines machines identiques à celles que j’avais avec EN PLUS le graal, un réseau privé virtuel entre dédiés (RPN).

Ces deux configs me disaient vraiment quelque chose… et pour cause ! OneProvider les revends en marque blanche.

Donc c’est exactement les mêmes machines que celle que j’ai pu avoir dans le passé, mais avec le RPN en plus, et un peu plus cher (beaucoup plus cher même).

Ce qui est dommage ici, c’est que le RPN ne soit pas disponible sur les machines un peu plus petites (mon PRA n’est pas aussi gros, juste de quoi faire tourner le blog en cas de gros crash).

Vient alors Hetzner

Ça fait pas mal de fois que je voyais circuler le nom. Des bloggeurs et d’autres confrères en disaient beaucoup de bien, et j’ai voulu aller voir. La première chose intéressante est que Hetzner, comme OVH et Online, propose bien un service de type réseau privé virtuel entre vos serveurs !

Plus de puissance chez Hetzner !

Par contre, quand j’ai vu les machines… au début je me suis dis que ça allait pas le faire…

Voilà leur machine "bas de gamme" :

Pour à peine plus que le moins cher des SoYouStart (un vieux Xeon E3 v2 4c/4t avec 16Go de RAM et 2 HDD), vous avez un tout nouveau Ryzen 5 6c/12t, 64 Go de RAM et un RAID de 2 SSD NVMe de 512 Go.

Bon clairement on était hors budget mais ils avaient piqué ma curiosité avec leurs config fofolles.

Et je suis donc tombé en fouillant un peu sur leur "server auction", qui est ni plus ni moins que les serveurs de leurs anciennes gammes qu’ils louent à nouveau. Et là c’était déjà plus proche de mon besoin.

Pour un peu plus de 30€/mois soit 50% plus que mon serveur précédent, mais comparable au prix Online, j’ai un i7-4770, 32 Go de RAM et 2 disques "Entreprise". Soit beaucoup mieux que la machine chez Online.

Quitte à changer, j’ai donc tenté Hetzner et commandé un serveur.

C’est puissant mais… qu’est ce que c’est moche

Bon, l’UI n’est pas follement attrayante. C’est… spartiate.

Dans le menu "Servers", vous avez une bête liste de vos serveurs avec le numéro de commande, un hostname (une fois que vous l’aurez setté) et un ID (peu parlant). Bof pratique, surtout au début ou si vous en avez beaucoup.

Et quand on sélectionne un serveur, ce n’est malheureusement guère mieux. Les informations importantes éclatées dans un nombre incalculable de menus.

Bref, côté expérience utilisateur, on repassera. Cependant, tout ce qu’il faut pour bien administrer son serveur est là. On finira par s’y retrouver avec un peu d’habitude…

Installation de l’hyperviseur

Pour installer notre serveur, on peut utiliser l’interface web pour installer un Debian, ou passer par l’image de rescue.

J’ai préféré utiliser la 2ème solution, car elle est immédiatement disponible à la livraison du serveur, avec votre clé SSH.

On arrive sur un login on ne peut plus classique, avec un résumé des caractéristiques de vos serveurs.

Point intéressant, il existe un binaire installimage sur l’OS rescue de Hetzner. Il permet, comme son nom l’indique, d’installer une image.

Comme j’utilise Proxmox VE comme hyperviseur, j’ai donc installé une Debian 10 :

Une fois l’image de base choisie, vous allez arriver à un éditeur de texte. Il va vous permettre de configurer de manière plus fine votre installation. Je trouve cette méthode assez originale. Ça change des interfaces webs pas toujours stables vous demandant la taille de vos partitions pour finalement planter dès que vous demandez un truc non standard.

Ici tout a très bien marché, j’ai configuré le hostname, ainsi qu’un RAID soft et un partitionnement LVM.

Là encore, je suis navré qu’on tombe dans le cliché, mais si ce n’est pas "joli" ni "user friendly", au moins c’est efficace.

Passer de Debian 10 à Proxmox VE 6

Une fois validé, l’image Debian 10 a été copié extrêmement rapidement (une ou deux minutes). Forcément, c’est une "minimal". Mais bon c’est quand même agréable d’avoir son serveur "up and running" en moins d’une demie heure entre la commande et la fin de l’installation.

Reste donc à installer PVE 6 sur notre dédié Hetzner. Sans trop de surprise, j’ai réutilisé mon playbook Ansible qui configure de A à Z la Debian pour en faire un Proxmox. Pour ceux qui l’ont loupé, c’est par ici que ça se passe.

J’ai juste eu un petit souci lors de l’installation. La debian étant minimale, je n’avais même pas python d’installé. C’est gênant quand on fait du Ansible !

cat inventory_hetzner.yml
all:
  children:
    proxmoxve:
      hosts:
        <fqdn_hyperviser>:

ansible proxmoxve -i inventory_hetzner.yml -u root -m ping
<fqdn_hyperviser> | FAILED! => {
    "changed": false,
    "module_stderr": "Shared connection to <fqdn_hyperviser> closed.\r\n",
    "module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
    "msg": "MODULE FAILURE",
    "rc": 127
}

Heureusement j’avais déjà eu le souci dans un autre contexte. J’ai donc écris un playbook supplémentaire (dispo sur le Github) pour installer les prérequis manquants.

ansible-playbook -i inventory_hetzner.yml -u root proxmox_python_firstinstall.yml
ansible-playbook -i inventory_hetzner.yml -u root proxmox_prerequisites.yml

Et en quelques minutes, mon Proxmox VE était opérationnel sur Hetzner !

Cet article Changement de provider, mon hyperviseur sur un dédié Hetzner est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/11/19/changement-de-provider-mon-hyperviseur-sur-un-dedie-hetzner/feed/ 7 5225
[Updated] Le support de ma conf’ Logiciel Libre à BDX I/O 2019 https://blog.zwindler.fr/2019/11/15/le-support-de-ma-conf-logiciel-libre-a-bdx-i-o-2019/ https://blog.zwindler.fr/2019/11/15/le-support-de-ma-conf-logiciel-libre-a-bdx-i-o-2019/#respond Fri, 15 Nov 2019 09:00:00 +0000 https://blog.zwindler.fr/?p=5234 Les slides de mon talk à BDX I/O 2019 : le (logiciel) libre a-t-il de beaux jours devant lui ?

Cet article [Updated] Le support de ma conf’ Logiciel Libre à BDX I/O 2019 est apparu en premier sur Zwindler's Reflection.

]]>
Normalement, j’ai suffisamment communiqué pour que ça ne soit une surprise pour personne, je suis speaker aujourd’hui à BDX I/O 2019. Une nouvelle fois, je vais donc pouvoir venir vous parler d’un sujet qui me tient à cœur, le logiciel libre et l’open source.

[Updated] La vidéo

L’organisation a DEJA mis à disposition les vidéos des talks sur Youtube ! Un grand bravo à eux

[Updated] Un sketchnote du talk

Mon ex-collègue Ane (@ane_naiz) a eu la gentillesse de faire un sketchnote de ma conférence. C’est tellement chouette que je vous le partage !!

Un énorme merci à elle

Le pitch

Comme vous pouvez le voir sur ce superbe montage, je serai donc à 10h15 en Amphi B pour vous parler Logiciel Libre et Open Source, avec le pitch suivant :

– 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 !).

Comme à mon habitude dans ce genre de cas, je vous met un tout petit peu avant de passer mes slides à dispositions, si jamais vous voulez suivre sur votre écran (et/ou suivre les liens que j’ai ajouté en source, car je source tout ce dont je parle ;-p).

Le support

J’espère sincèrement que ça vous plaira, et surtout, prenez le temps de voter, ça permettra à l’orga de BDX I/O 2019 de savoir s’il faut me sélectionner à nouveau l’an prochain ou pas ;-)

Cet article [Updated] Le support de ma conf’ Logiciel Libre à BDX I/O 2019 est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/11/15/le-support-de-ma-conf-logiciel-libre-a-bdx-i-o-2019/feed/ 0 5234
[Tutoriel] Installer Prometheus/Grafana sans Docker https://blog.zwindler.fr/2019/11/12/tutoriel-installer-prometheus-grafana-sans-docker/ https://blog.zwindler.fr/2019/11/12/tutoriel-installer-prometheus-grafana-sans-docker/#respond Tue, 12 Nov 2019 07:30:45 +0000 https://blog.zwindler.fr/?p=5220 Tutoriel pas à pas pour installer un Prometheus et un Grafana sur un serveur Linux et sans utiliser Docker

Cet article [Tutoriel] Installer Prometheus/Grafana sans Docker est apparu en premier sur Zwindler's Reflection.

]]>

Prometheus et Grafana dans Docker, quelle horreur ?

Je sais que certains d’entre vous ne sont pas super fan (euphémisme) de la technologique containers Docker (et je ne parle même pas de Kubernetes, cf Concerning Kubernetes). Pour autant, pas besoin de Docker pour avoir besoin du couple Prometheus / Grafana.

Prometheus a plein de features sympas (notamment l’auto discovery, le langage de requêtage PromQL, …). De son côté, Grafana est vraiment top pour ce qui est visualisation rapide provenant de plusieurs sources de données.

Peut être même que vous avez du Docker (ou même Kubernetes) mais que vous n’avez pas envie d’intégrer la supervision dans votre infra de compute.

Il y a plein de bonnes raisons pour ça, comme ne pas vouloir héberger la supervision sur l’infra qu’elle est censé surveillée ou encore pour des problématiques de performances, …

Avec Docker, lancer Prometheus ou Grafana se fait en une ligne de commande, c’est pour ça qu’on voit cette manière de faire partout. Sans Docker, c’est nécessairement un poil plus compliqué (mais à peine) à faire. Et c’est pourquoi je fais ce petit tuto rapide.

Prometheus

Dans ce tuto, on va partir des sources. Pour Prometheus, vous pourrez trouver un raccourci vers la dernière version sur le site officiel.

On télécharge cette version et on configure un utilisateur exécuter Prometheus

wget https://github.com/prometheus/prometheus/releases/download/v2.13.1/prometheus-2.13.1.linux-amd64.tar.gz
tar xzf prometheus-2.13.1.linux-amd64.tar.gz
sudo mv prometheus-2.13.1.linux-amd64/ /usr/share/prometheus

sudo useradd -u 3434 -d /usr/share/prometheus -s /bin/false prometheus
sudo mkdir -p /var/lib/prometheus/data
sudo chown prometheus:prometheus /var/lib/prometheus/data
sudo chown -R prometheus:prometheus /usr/share/prometheus

Une fois que c’est fait, le mieux c’est de tester que Prometheus "fonctionne" correctement en le lançant à la main pour voir si le logiciel se lance bien, avec la configuration par défaut.

/usr/share/prometheus/prometheus --config.file=/usr/share/prometheus/prometheus.yml
[...]
level=info ts=2019-09-20T14:56:18.244Z caller=main.go:768 msg="Completed loading of configuration file" filename=/usr/share/prometheus/prometheus.yml
level=info ts=2019-09-20T14:56:18.244Z caller=main.go:623 msg="Server is ready to receive web requests."

Ici tout s’est bien passé, on peut donc le couper (Ctrl-C) et créer un script SystemD pour pouvoir le démarrer automatiquement avec le serveur.

sudo vi /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network-online.target

[Service]
User=prometheus
Restart=on-failure
WorkingDirectory=/usr/share/prometheus
ExecStart=/usr/share/prometheus/prometheus --config.file=/usr/share/prometheus/prometheus.yml

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable prometheus
sudo systemctl start prometheus
sudo systemctl status prometheus

Grafana

Maintenant que c’est fait, on passe à Grafana. Vous allez voir, ça va aussi vite.

Dans le cas de Grafana, la méthode mise en avant sur le site officiel est l’utilisation des packages systèmes (".deb" pour Debian ou Ubuntu, RPM pour CentOS). Par souci de cohérence dans l’article, je ne vais pas utiliser le .deb et installer le binaire précompilé pour l’installer de la même manière que Prometheus. Cependant, le .deb aurait très bien fait l’affaire (et ça ira plus vite si vous êtes pressés).

On télécharge donc la version précompilée, on positionne les bons dossiers/binaires/fichiers de config aux bons endroits.

wget https://dl.grafana.com/oss/release/grafana-6.4.4.linux-amd64.tar.gz
tar -xzf grafana-6.4.4.linux-amd64.tar.gz

sudo useradd -d /usr/share/grafana -s /bin/false grafana
sudo mkdir -p /var/lib/grafana/plugins /etc/grafana /var/log/grafana
sudo chown -R grafana:grafana /var/lib/grafana

sudo mv grafana-6.4.4/ /usr/share/grafana
sudo cp /usr/share/grafana/bin/grafana-server /usr/sbin/
sudo cp /usr/share/grafana/conf/sample.ini /etc/grafana/grafana.ini

On configure systemD puis on démarre le service.

sudo vi /etc/default/grafana-server
GRAFANA_USER=grafana
GRAFANA_GROUP=grafana
GRAFANA_HOME=/usr/share/grafana
LOG_DIR=/var/log/grafana
DATA_DIR=/var/lib/grafana
MAX_OPEN_FILES=10000
CONF_DIR=/etc/grafana
CONF_FILE=/etc/grafana/grafana.ini
RESTART_ON_UPGRADE=true
PLUGINS_DIR=/var/lib/grafana/plugins
PROVISIONING_CFG_DIR=/etc/grafana/provisioning
PID_FILE_DIR=/var/run/grafana
sudo vi /etc/systemd/system/multi-user.target.wants/grafana-server.service
[Unit]
Description=Grafana instance
Documentation=http://docs.grafana.org
Wants=network-online.target
After=network-online.target
After=postgresql.service mariadb.service mysql.service

[Service]
EnvironmentFile=/etc/default/grafana-server
User=grafana
Group=grafana
Type=simple
Restart=on-failure
WorkingDirectory=/usr/share/grafana
RuntimeDirectory=grafana
RuntimeDirectoryMode=0750
ExecStart=/usr/sbin/grafana-server                                                  \
                            --config=${CONF_FILE}                                   \
                            --pidfile=${PID_FILE_DIR}/grafana-server.pid            \
                            cfg:default.paths.logs=${LOG_DIR}                       \
                            cfg:default.paths.data=${DATA_DIR}                      \
                            cfg:default.paths.plugins=${PLUGINS_DIR}                \
                            cfg:default.paths.provisioning=${PROVISIONING_CFG_DIR}


LimitNOFILE=10000
TimeoutStopSec=20
UMask=0027

[Install]
WantedBy=multi-user.target
systemctl start grafana-server
systemctl enable grafana-server
systemctl status grafana-server
[...]
Nov 10 15:40:17 nostromo grafana-server[14606]: t=2019-11-10T15:40:17+0000 lvl=info msg="Initializing Stream Manager"
Nov 10 15:40:17 nostromo grafana-server[14606]: t=2019-11-10T15:40:17+0000 lvl=info msg="HTTP Server Listen" logger=http.server address=0.0.0.0:3000 protocol

On cable le tout ensemble

Vous avez vu, je vous avais pas menti, c’est assez simple en fait.

Maintenant que Prometheus et Grafana tournent, on va les coufigurer pour qu’ils parlent ensemble.

Tout se passe sur l’interface d’administration de Grafana, qui devrait maintenant être accessible à l’URL http://<IP_de_votre_serveur>:3000

Authentifiez vous en tant qu’administrateur. Par défaut à la première instanciation, seul un compte "admin" est créé, avec le mot de passe hautement sécurisé "admin". Heureusement on change ça tout de suite…

La dernière étape consiste à simplement se rendre dans la partie administration de Grafana, puis de créer un source de données.

Il existe de nombreuses sources de données différentes. Nous dans notre cas, c’est bien une source de type Prometheus qu’on veut créer.

Renseignez simplement l’URL d’accès à Prometheus (par défaut http://localhost:9090 dans ce tutoriel) et sauvez.

A partir de maintenant, vous avez un couple Prometheus / Grafana fonctionnel. Vous allez pouvoir commencer à créer des Dashboard.

Enjoy !

Cet article [Tutoriel] Installer Prometheus/Grafana sans Docker est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/11/12/tutoriel-installer-prometheus-grafana-sans-docker/feed/ 0 5220
Récap’ du RabbitMQ Summit 2019 https://blog.zwindler.fr/2019/11/05/recap-du-rabbitmq-summit-2019/ https://blog.zwindler.fr/2019/11/05/recap-du-rabbitmq-summit-2019/#respond Tue, 05 Nov 2019 12:45:09 +0000 https://blog.zwindler.fr/?p=5204 Récapitulatif de la conférence RabbitMQ Summit 2019 à Londres

Cet article Récap’ du RabbitMQ Summit 2019 est apparu en premier sur Zwindler's Reflection.

]]>

Des lapins partout, nous étions au RabbitMQ Summit !

Dimanche soir, je suis arrivé à Londres pour participer, avec deux de mes collègues, au RabbitMQ Summit 2019. Cette journée est dédiée à mon broker de messages préféré, RabbitMQ (et non ce n’est pas Kafka — ceci est un troll gratuit pour mes collègues).

Pour ceux qui n’auraient pas suivi, j’ai déjà écris quelques articles sur le sujet dont une introduction si vous débutez.

Cette journée a été l’occasion de pouvoir faire le plein de bonnes pratiques, REX, et autres protips pour optimiser nos clusters.

Keynote

Sans surprise, la keynote d’introduction était réalisée par des membres de la core team de RabbitMQ (Diana ParraCorbacho et Michael Klishin), qui ont parlé de l’actualité du Broker.

Une version majeure de RabbitMQ est sortie en octobre (la 3.8) et de nombreuses des features annoncées l’an dernier sont maintenant utilisables.

Je suis particulièrement enthousiaste à propos des quorum queues et des métriques Prometheus natives, qui sont clairement les deux stars de cette édition, avec plusieurs talks dédiés ou y faisant référence.

L’ajout de features flags pour faciliter les mises à jours (présents à partir de la 3.7.20+ ou 3.8+) est clairement un autre gros point positif. Michael Klishin a officiellement indiqué que le blue/green deployment n’était désormais plus la seule méthode supportée pour mettre un cluster à jour.

La 3.8 étant maintenant derrière nous (seulement des bugs fix sortiront à partir de maintenant), cap sur la 3.9 !

Dans les points importants, un travail va être réalisé pour rendre le core de chaque protocole identique. En effet, aujourd’hui, chaque protocole supporté par RabbitMQ est un module spécifique. Une refonte de l’UI est aussi prévue.

Dans les annonces, une version entreprise (RabbitMQ Entreprise Edition) devrait également voir le jour dans les mois qui viennent. Identique à la version communautaire dans les grandes lignes, elle intégrera des modifications supplémentaires pour faciliter l’hébergement de cluster RabbitMQ inter-connecté sur un WAN ou crossDC. Bien évidemment un support pro fera parti du package.

Le dernier point abordé, pour le futur, est le gros travail sur le "moteur de stockage" utilisé par RabbitMQ (pour la configuration et la persistance). Aujourd’hui, ce travail est réalisé par un projet annexe appelé Mnesia. Michael Klishin a insisté sur le fait que même si le code restait pertinent, la base de code était elle vieillissante.

Un nouveau projet Mnevis avait donc été lancé. Cette réécriture de 0 à pour but de mieux prendre en compte des problématiques multi DC et une meilleure reprise sur incident.

Même si Mnevis ne sera pas officiellement pas disponible pour tout de suite, (probablement pas avant la version 4) un prototype devrait être disponible avec une version modifiée de RabbitMQ. Les sources de Mnevis sont disponibles ici. On aura certainement plus d’infos au prochain RabbitMQ Summit !

Practical Advice for the Care & Feeding of RabbitMQ

La keynote passée, Gavin Roy a présenté un REX sur plus de 10 ans d’utilisation de RabbitMQ en production, avec les pièges dans lesquels lui et son équipes étaient tombés.

De soucis de code PHP qui ouvrait des connexions éphémères (coûteuses dans RabbitMQ), jusqu’à l’envoi de messages contenant des payloads (alors que AMQP propose d’ajouter des metadata), en passant par des lenteurs dues à des erreurs de configuration, le talk a été riche en bonnes pratiques (ou plutôt, mauvaises pratiques à éviter !).

Même si certaines erreurs peuvent sembler faciles à éviter (surtout avec le recul), c’est un de mes talks préférés de la journée, avec de nombreuses réflexions à venir, une fois rentré.

Prometheus Export

C’est le 2ème gros sujet de la journée. J’ai assisté à la présentation de l’ajout de métriques natives au format OpenMetrics directement dans RabbitMQ.

Un des gros soucis de l’interface de management actuelle et des métriques qu’elle expose est qu’il est nécessaire de disposer de privilèges important pour les consulter. Dans un contexte multi-équipes (ou multitenant), ce n’est pas pratique. Le second est un problème de performance. Actuellement l’interface de management (plugin de RabbitMQ) arrive parfois à saturation, nécessitant en cas de charge plusieurs dizaines de secondes à s’afficher.

Pour éviter ces soucis, certains d’entre vous utilisent peut être le rabbitmq-exporter, qui récupère les données de la management UI et les expose à Prometheus au format OpenMetrics. Cependant, ce client, tributaire de la management UI, est nécessairement également limité en cas de surcharge.

La vraie solution qui vient de sortir en 3.8 est donc l’exposition native de métriques au format OpenMetrics. Cet ajout a a priori déjà été énormément bénéfique à RabbitMQ et son écosystème, permettant de déceler plusieurs portions de code inefficientes dans le code de RabbitMQ et même dans le code de Erlang (bugs fixés depuis).

Après déjeuner, 2 talks… un peu décevant…

Les talks suivants ("Source oriented exchanges pattern to keep events in order" et "RabbitMQ MQTT versus EMQX") ne sont pas simples à retranscrire.

Le premier était très générique, sur la façon de gérer correctement un processus nécessitant que les messages soient traités dans l’ordre.

Le second, un peu étonnant, comparait RabbitMQ avec un produit concurrent au travers du scope MQTT et sur un usecase très précis.

Quelques points que j’ai retenu :

  • j’ai raté un talk de Wework qui parle de sharding et qui est probablement intéressant à (re)voir (Wework’s "good enough" order guarantee, je mettrai à jour le lien)
  • il existe un outil appelé MZ Tool (???) qui permet de stress-tester vos infrastructures MQTT. Ce dernier peut être piloté par Ansible ou Terraform. J’ai trouvé un projet MZ-Tools qui n’a rien à voir… Je continue à chercher.

RabbitMQ at Scale

Partenaires principaux du RabbitMQ Summit, les gens de Code84 (CloudAMQP) étaient présents, en nombre ! La société est spécialisée dans l’hébergement de serveurs RabbitMQ, mais aussi de Kafka, PostgreSQL et Mosquitto en mode PaaS. La société est également connue sur son blog technique pléthorique.

Lovisa Johansson (qui a écrit la plupart des articles du blog, que je recommande chaudement) et Anders Bälter nous ont présenté le cheminement de leur société depuis 2012. En partant de simples API Heroku et de serveurs AWS, la plateforme hébergement maintenant les serveurs RabbitMQ de milliers de clients, tout en publiant des métriques, des logs, des alertes, vers la plupart des composants SaaS connus.

Ce talk a aussi été l’occasion de présenter quelques statistiques d’utilisation, notamment sur les moyennes/maximums de métriques comme le nombre de messages par secondes, le nombre de vhosts ou de policy, etc.

Feature complete: uncovering the true cost of different rabbitmq features and configurations

Le dernier talk auquel que nous avons vu a été donné par Jack Vanlightly, qui travaille maintenant chez Pivotal (l’éditeur de RabbitMQ).

Ce talk a été extrêmement riche et mérite d’être revu, à tête reposée.

Jack Vanlightly a fait une série de bench sur plusieurs types de serveurs, avec diverses compositions de producers/consumers, types d’exchanges et d’autres paramètres moins connus.

Les cas étaient parfois extrêmes, mais je pense que les différents cas qu’ils illustrent s’avéreront utiles pour tuner des comportements d’apparence anormaux dans des cas réels (quel paramètre tuner en fonction du nombre de consumers ou de la latence du réseau par exemple).

Conclusion

Malgré notre envie de rester jusqu’au bout, nous devions partir pour arriver à l’heure pour notre vol retour.

Ce RabbitMQ Summit a été l’occasion de discuter avec d’autres utilisateurs de RabbitMQ et de revoir les bonnes pratiques avec des professionnels qui en hébergent des milliers (600000 connexions actives chez CloudAMQP tout de même !).

Ça a aussi été l’occasion de voir que nous n’étions pas aussi "petits" que nous pensions dans notre usage de RabbitMQ, même si nous sommes très loin des limites de l’application dans nos cas d’usage !

Les joies du Dual Tracks ont fait que nous avons forcément raté certains talks que nous aurions voulu voir… Heureusement qu’il y aura les vidéos sur YouTube dans quelques jours/semaines !

A refaire, donc !

Cet article Récap’ du RabbitMQ Summit 2019 est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/11/05/recap-du-rabbitmq-summit-2019/feed/ 0 5204
kubectl tips and tricks n°1 https://blog.zwindler.fr/2019/10/30/kubectl-tips-tricks-1/ https://blog.zwindler.fr/2019/10/30/kubectl-tips-tricks-1/#respond Wed, 30 Oct 2019 07:00:44 +0000 https://blog.zwindler.fr/?p=4862 Ensemble de tips and tricks rarement mis en avant pour améliorer votre productivité sur Kubernetes avec kubectl

Cet article kubectl tips and tricks n°1 est apparu en premier sur Zwindler's Reflection.

]]>

kubectl

Ça fait un moment que je garde sous le coudes quelques petites tips pour améliorer votre productivité via la CLI de Kubernetes kubectl.

Rassurez vous, je ne vais pas faire un énième article sur l’autocomplétion ou autre info triviale comme "vous savez que vous pouvez stocker plusieurs contexts dans votre kubectl ?" #shocking. (Si ce dernier point vous intéresse, j’avais fais un article sur kubectx et kubens qui va surement vous plaire).

Normalement, les astuces que je vais vous montrer ici ne sont pas dans la plupart des tutos que j’ai pu trouver sur le net.

C’est parti pour du fun avec kubectl !

Pour les accrocs à la flèche du haut

Si, comme moi, vous faites partie de ces gens impatients qui ne peuvent pas prendre un café le temps qu’une opération se termine toute seule et que vous appuyez frénétiquement une la combinaison "flèche du haut + entrée" pour rappeler la dernière commande "kubectl get monobjetquejattendavecimpatience", ce paragraphe est pour vous.

Lors d’une commande de type "get" avec kubectl, il existe un flag "-w" qui fait… oui vous l’avez deviné… un genre de watch sur le (ou les) objet(s) que vous attendez.

Par exemple, dans le cas où vous souhaiteriez créer un objet Service de type LoadBalancer et que vous avez hâte que votre cloud provider vous assigne une IP publique, utilisez la commande suivante :

kubectl --context=cephk8s get svc traefik-ingress-controller --namespace kube-system -w
NAME                         TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)                      AGE
traefik-ingress-controller   LoadBalancer   10.0.21.75   <pending>     80:32347/TCP,443:30388/TCP   45s
traefik-ingress-controller   LoadBalancer   10.0.21.75   40.89.187.183   80:32347/TCP,443:30388/TCP   56s

Dans un premier temps, seul la première ligne LoadBalancer s’affichera (tant que l’état restera à "Pending"), puis dès qu’il y aura une modification, la dernière ligne, avec l’IP publique, s’affichera.

C’est également pratique si vous avez des Pods qui mettent du temps à s’initialiser dans un Déploiement complexe.

Relancer un job

Kubernetes, en bon orchestrateur qu’il est, est capable de lancer des tâches planifiées. C’est super pratique lorsque vous avez des tâches bien précises à réaliser mais qu’il n’y a pas de raison de laisser un container tourner H24 pour ça.

On a donc la notion d’objet Kubernetes Job et de Cronjob. Sans rentrer dans les détails, le Job, c’est celui qui exécute la tâche (il lance un Pod qui contient un ou plusieurs containers). Le Cronjob, c’est une surcouche qui lance périodiquement le Job. Rien de bien sorcier.

Malheureusement pour nous, il arrive que nos Jobs échouent. Il n’y avait pas assez de ressources, ou alors on est tombé sur un bug, ou alors c’est "la faute à pas de chance".

Qu’à cela ne tienne, il faut que votre Job tourne aujourd’hui, vous voulez donc le relancer. Pas de chance pour vous, "by design", les Jobs ne peuvent pas être relancés dans Kubernetes.

Jusqu’à récemment, il n’y avait pas de solution propre pour relancer un Job avec kubectl. Il fallait donc passer par un exposer du JSON du Job pour en recréer un nouveau identique en tout point. "Crude but effective" comme disent nos amis anglosaxons.

kubectl --context=moncontext --namespace=monnamespace get job monjob -o json | jq 'del(.spec.selector)' | jq 'del(.spec.template.metadata.labels)' | kubectl --context=moncontext --namespace=monnamespace replace --force -f -

Si vous voulez plus de détails sur ce que oneliner fait vraiment : la première partie dump en JSON la configuration du job, la partie du milieu retire les données spécifiques au Job qui a échoué (autogénéré à la création du Job) et la dernière partie réinjecte le job dans Kubernetes, ce qui a pour effet de le relancer.

Pas mal hein ?

Mais… si vous avez une version plus récente, vous avez de la chance, cette option est maintenant disponible par défaut dans kubectl, vous permettant de créer de manière unitaire un Job à partir d’un template contenu dans un Cronjob, ce qui revient au même.

kubectl --context=moncontext --namespace=monnamespace create job --from=cronjob/lecronjobmaitre unnomuniquepourlejobrelancé

Les selecteurs dans vos kubectl

Last but not least, il est possible de réaliser des opérations sur plusieurs objets d’un même type en même temps.

La manière la plus simple de le faire est simplement d’ajouter les noms de tous les objets à la fin de votre commande. Par exemple, la commande suivante va supprimer les Pods pod1, pod2 et pod1000 :

kubectl --context=moncontexte --namespace==monnamespace delete pods pod1 pod2 pod1000

Cependant, on va rarement supprimer des pods (ou autre objet) au hasard. Généralement, on va vouloir supprimer tous les pods d’un même déploiement, ou alors supprimer tous les objets de la même applications, ou encore scaler tous les déploiements d’un même client.

Dans tous les cas, si vous avez bien fait votre travail, tous ces objets Kubernetes auront tous les labels cohérents les uns avec les autres. En partant du principe que les pods de l’exemple précédents ont tous le label app=blopiblop, je peux donc exécuter la commande suivante pour gagner du temps :

kubectl --context=moncontexte --namespace==monnamespace delete pods --selector=app=blopiblop

Attention à ne pas vous tromper dans les labels, c’est très puissant ;-)

Cet article kubectl tips and tricks n°1 est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/10/30/kubectl-tips-tricks-1/feed/ 0 4862
CNCF Bdx #6 : les slides de mon talk Thanos https://blog.zwindler.fr/2019/10/24/cncf-bdx-6-les-slides-de-mon-talk-thanos/ https://blog.zwindler.fr/2019/10/24/cncf-bdx-6-les-slides-de-mon-talk-thanos/#respond Thu, 24 Oct 2019 17:00:10 +0000 https://blog.zwindler.fr/?p=5188 Les slides de mon talk "Besoin de métriques Prometheus à long terme ? Thanos fera des Marvels !" au CNCF Meetup de Bordeaux #6

Cet article CNCF Bdx #6 : les slides de mon talk Thanos est apparu en premier sur Zwindler's Reflection.

]]>
Ce soir, je donne un talk sur Thanos au CNCF Meetup de Bordeaux. Comme d’habitude, je met à disposition les slides quelques minutes avant. [Le lien du Meetup pour les curieux]

Besoin de métriques Prometheus à long terme ? Thanos fera des Marvels !

Prometheus, aussi puissant soit il, repose sur plusieurs postulats qui ne collent pas avec tous les cas d’usage. Les métriques doivent être stockées sur un medium local et rapide, il faut un serveur par zone (failure domain) et donc potentiellement un grand nombre de serveurs Prometheus indépendants, difficiles à corréler, …
Arrive alors Thanos (rien à voir avec le bonhomme violet avec un gant doré) !
Celui ci va nous permettre de stocker nos métriques infiniment, tout en les rassemblant au sein d’une même source de données et en améliorant la performance de nos requêtes les plus coûteuses.

Les slides, les slides !

Et voilà les slides :-D

Le podcast, le podcast !

Si je n’oublie pas de lancer l’enregistrement, je mettrais aussi un fichier audio de la conf, en mode podcast :-p.

Cet article CNCF Bdx #6 : les slides de mon talk Thanos est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/10/24/cncf-bdx-6-les-slides-de-mon-talk-thanos/feed/ 0 5188
CNCF Meetup Bordeaux #6 : Tour d’horizon du monitoring dans Kubernetes https://blog.zwindler.fr/2019/10/14/cncf-meetup-bordeaux-6-tour-dhorizon-du-monitoring-dans-kubernetes/ https://blog.zwindler.fr/2019/10/14/cncf-meetup-bordeaux-6-tour-dhorizon-du-monitoring-dans-kubernetes/#respond Mon, 14 Oct 2019 15:30:18 +0000 https://blog.zwindler.fr/?p=5184 Je donne une nouvelle fois un Talk au CNCF Meetup de Bordeaux, cette fois ci sur Thanos, après une première partie sur Prometheus

Cet article CNCF Meetup Bordeaux #6 : Tour d’horizon du monitoring dans Kubernetes est apparu en premier sur Zwindler's Reflection.

]]>
CNCF Meetup Bordeaux

Et rebelotte !

Je récidive et vais de nouveau venir vous raconter comment je travaille au CNCF Meetup de Bordeaux (pour rappel, vous pouvez retrouver les slides de mon passage précédent, dans lequel j’avais fais un REX des incidents qu’on a eu sur Kubernetes).

Pour cette 6ème édition, ça se passera le 24 octobre à partir de 19h00 dans les locaux de « Le Wagon » à Bordeaux.

Le lien vers le meetup et l’inscription

Si vous êtes du coin et que vous êtes de passage et que vous voulez échanger avec vos pairs sur les solutions open sources de containerisation et autres sujets ayant trait au cloud, c’est « the place to be ».

Comme d’habitude, attention car les places partent très vite. Généralement, en 2 jours c’est plié…

CNCF ?

Pour rappel, la Cloud Native Computing Foundation, c’est la fondation « spin-off » de la Linux Foundation qui a été créée pour fédérer, piloter, organiser l’ensemble des projets open source ayant trait aux containers, aux microservices et aux services clouds.

The Cloud Native Computing Foundation builds sustainable ecosystems and fosters
a community around a constellation of high-quality projects that orchestrate
containers as part of a microservices architecture.

Elle a été créée lorsque Google a légué le code de Kubernetes en 2015.

Le programme

A 19H15, Etienne Coutaud, le co organisateur, nous fera son traditionnel « tour des news de l’écosystème CNCF ».

#1 Monitorer mon cluster Kubernetes (quasiment) sans les mains.

A 19h30, Etienne embraye sur la supervision avec Prometheus dans Kubernetes

Il est impensable de mettre une plateforme en production sans monitoring, ceci est aussi vrai pour du Kubernetes managé ou non. Kubernetes est designé pour s’intégrer parfaitement avec un autre produit phare de la CNCF Prometheus. Nous verrons durant ce talk comment mettre en œuvre les deux, comment cela s’architecture et comment l’opérer. Nous verrons également comment cette architecture est faite pour nativement accueillir les métriques issus de votre propre code.

#2 Besoin de métriques Prometheus à long terme ? Thanos fera des Marvels !

Et ensuite, c’est mon tour. J’irai un peu plus loin avec Prometheus en vous parlant de Thanos.

Prometheus, aussi puissant soit il, repose sur plusieurs postulats qui ne collent pas avec tous les cas d’usage. Les métriques doivent être stockées sur un medium local et rapide, il faut un serveur par zone (failure domain) et donc potentiellement un grand nombre de serveurs Prometheus indépendants, difficiles à corréler, …
Arrive alors Thanos (rien à voir avec le bonhomme violet avec un gant doré) !
Celui ci va nous permettre de stocker nos métriques infiniment, tout en les rassemblant au sein d’une même source de données et en améliorant la performance de nos requêtes les plus coûteuses.

Lier l’utile à l’agréable

A 21h, nous nous retrouverons pour échanger autour d’une bière et d’une part de pizza offert par Gekko (Merci à eux :-D).

Cet article CNCF Meetup Bordeaux #6 : Tour d’horizon du monitoring dans Kubernetes est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/10/14/cncf-meetup-bordeaux-6-tour-dhorizon-du-monitoring-dans-kubernetes/feed/ 0 5184
Un cluster Proxmox VE avec seulement 2 machines ! https://blog.zwindler.fr/2019/10/11/un-cluster-proxmox-ve-avec-seulement-2-machines/ https://blog.zwindler.fr/2019/10/11/un-cluster-proxmox-ve-avec-seulement-2-machines/#respond Fri, 11 Oct 2019 06:40:55 +0000 https://blog.zwindler.fr/?p=5136 Mise en place d'un vote externe au cluster PVE pour permettre d'éviter le psplit brain dans les cas où ce risque est plausible

Cet article Un cluster Proxmox VE avec seulement 2 machines ! est apparu en premier sur Zwindler's Reflection.

]]>

Depuis le temps que je vous parle de clusters et de Proxmox (en gros, depuis 2015), ou même de clusters tout court, j’ai pu vous en mettre des tartines sur le fait qu’il ne faut pas faire des clusters avec un nombre pair de machines (ou tout autre cas défavorable dans lequel deux moitiés d’un cluster peuvent se retrouver isolées l’une de l’autre). Le split brain, c’est pas bon pour votre Karma, croyez moi sur parole (ou allez voir vous même).

Ça me rappelle la fois où un """architecte""" de chez Datacore était venu nous expliquer que sa solution de stockage à 2 pattes ne POUVAIT PAS avoir de split brain (alors que si, les ingés du support ont du repasser par derrière pour nous dire que "oui désolé vous avez évidemment raison c’est un cas possible" #LOL).

Bref, et donc à force d’en parler, il fallait bien quand même que je donne un jour la solution pour le faire quand même, mais proprement. Sans trop de surprise, Corosync, la librairie qui gère les clusters Linux depuis qu’on a arrêté de faire des horreurs avec heartbeat (ou pire : cman+rgmanager, achevez moi), gère évidemment les deux possibilités :

  • Gérer soit même le membre prioritaire en cas de split brain avec un poids (ça on va pas en parler mais sachez que c’est possible)
  • Ajouter un vote externe pour obtenir un quorum (comme tous les vrais logiciels qui font du clustering un peu sérieux quoi)

Limitations du "Corosync External Vote" dans PVE

La petite déception du jour viendra surtout du fait que, si la documentation de Proxmox VE indique clairement que l’option est supportée, en réalité, le support se limite aux fonctions natives de corosync, et encore pas toutes.

Pas moyen de voir notre vote externe dans l’interface de Proxmox VE par exemple. A priori, le support des quorum disk n’est plus assuré non plus depuis la version 4 de PVE.

Ensuite, il faut aussi savoir que pour l’instant, seul l’utilisation d’une IP pour renseigner le quorum serveur est possible. On ne peut pas utiliser un FQDN, ce qui me parait dingue comme limitation en 2019, mais bon…

Ces deux points mis de côté, vous allez voir, ce n’est pas sorcier. La procédure est en bonne partie détaillée dans la documentation.

Prérequis

Pour ce tutoriel, vous allez donc avoir besoin de 2 machines (a minima), déjà en cluster. Si vous ne les avez pas déjà, je vous invite à regarder les moults tutoriels précédents, en particulier celui sur la mise en place d’un cluster Proxmox VE 6 (le plus récent).

Vous allez aussi avoir besoin d’un serveur tiers (un bout de VM ou de container quelque part, en dehors de vos 2 (ou tout autres quantité de machines étant localisées dans 2 endroits distincts dont il existe un risque qu’ils puissent subitement "ne plus se voir", d’un point de vue réseau, induisant le fameux split brain tant redouté).

Fun fact, il y a une page de wiki pour faire la même chose à la main avec un RPi.

Ce serveur tiers n’a pas besoin de faire fonctionner Proxmox (c’est même plutôt mieux d’ailleurs car PVE n’a aucune plus-value ici). Ça doit juste être une distrib linux capable d’installer un démon corosync qnetd. Ce serveur, nous l’appellerons "quorum", par abus de langage grossier ;-).

Configuration

Sur le serveur quorum, installer corosync qnetd. Sur une Debian like, vous avez de la chance, il existe un package présent dans les dépôts par défaut, et il faut simplement faire un :

sudo apt install corosync-qnetd

Ensuite, sur tous les serveurs Proxmox VE de notre clsuter, on va installer le package corosync-qdevice, qui va leur permettre d’interroger le quorum.

sudo apt install corosync-qdevice

Sur le serveur quorum de nouveau, ajouter la clé SSH d’un des serveurs PVE (un seul suffit). Une fois que c’est fait, connecter le cluster au quorum.

Cela va sans dire, mais faire la commande depuis le serveur dont on vient d’ajouter la clé, pas l’autre hein ;-p. Et remplacez <QDEVICE-IP> par l’IP du serveur quorum !

pvecm qdevice setup <QDEVICE-IP>
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
The authenticity of host 'x.x.x.x' can't be established.
ECDSA key fingerprint is SHA256:LPaaaaaaaaaaaaaaaaaPZjaIg.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
 (if you think this is a mistake, you may want to use -f option)

Je met volontairement une grosse partie de la trace car comme ça on peut parler de ce que fait la commande pvecm qdevice setup x.x.x.x.

Comme vous pouvez le constater, cette commande semble assez similaire à celle pour créer manuellement le cluster. A savoir, elle commence déjà par copier les clés SSH sur le serveur distant, histoire que tout le monde puisse discuter ensemble en SSH.

INFO: initializing qnetd server
Certificate database (/etc/corosync/qnetd/nssdb) already exists. Delete it to initialize new db
INFO: copying CA cert and initializing on all nodes
node 'pve01': Creating /etc/corosync/qdevice/net/nssdb
password file contains no data
node 'pve01': Creating new key and cert db
node 'pve01': Creating new noise file /etc/corosync/qdevice/net/nssdb/noise.txt
node 'pve01': Importing CA
[...]

Ensuite, on initialise, sur tous les nodes du cluster, le qdevice, qui va permet au node de communiquer avec le quorum. Là j’élude un peu car ça parle beaucoup de certificats et de clés qui sont échangées.

INFO: copy and import pk12 cert to all nodes<br>INFO: add QDevice to cluster configuration
INFO: start and enable corosync qdevice daemon on node 'pve01'...
Synchronizing state of corosync-qdevice.service with SysV service script with /lib/systemd/systemd-sysv-install.

Normalement, si tout se passe bien, vous devriez en arriver là, une fois que tout le monde s’est bien échangé ses certificats, clés et autres joyeusetés crytographiques.

Une petite commande pour vérifier l’état du bazar :

$ pvecm status
Quorum information
------------------
Date:             Mon Aug 26 14:49:14 2019
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000002
Ring ID:          1/1271796
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate Qdevice 

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
0x00000001          1    A,V,NMW 10.0.0.1
0x00000002          1    A,V,NMW 10.0.0.2 (local)
0x00000000          1            Qdevice

Ça, c’est le genre de choses que j’attends d’un logiciel de clustering digne de ce nom. D’une simple commande, on peut avoir

  • le nombre de nodes
  • l’ID du node courant
  • le nombre de votes actuels, attendus, et minimum pour que le cluster soit "QUORATE"
  • et enfin l’état de tout le cluster.

Ici, avec 2 nodes + le quorum, on a bien 3 votes. Tant qu’on a 2 votes, on a le quorum, CQFD.

Dans ce cas de figure, si on perd un nœud OU le quorum, on a toujours 2 votes et le cluster doit continuer à fonctionner "normalement".

Et c’est ce qu’on va vérifier !

On casse un nœud, pour voir

Normalement, si on a pas le serveur quorum, tout devrait être brisé (comme dirait Medieval Ops).

Pour ceux qui ne connaissent pas Medieval Ops, j’avais envie de le placer parce que c’est drôle.

En gros les VMs doivent continuer à tourner, mais toute opération (démarrage de VM, modification quelconque) doit être bloquée (pour éviter de démarrer la même VM à 2 endroits et pleurer pour recoller les morceaux).

Or ici dès que l’hôte n’est plus joignable, le nœud survivant le détecte, et comme le quorum ne voit plus lui non plus qu’un seul nœud, indique au dernier qu’il peut continuer sa vie comme si de rien n’était (c’est glauque…).

$ pvecm status
Quorum information
------------------
Date:             Thu Aug 29 11:10:31 2019
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000002
Ring ID:          1/1271820
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      2
Quorum:           2  
Flags:            Quorate Qdevice 

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
0x00000002          1    A,V,NMW 10.0.0.2 (local)
0x00000000          1            Qdevice

Le nombre de vote passe bien à 2 (mais comme on est toujours égal à quorum c’est bon) et le node 1 a bien disparu :

Et la petite déception, pas de visualisation en console du vote du quorum, malgré la mention "Quorate"

Mais bon, c’est quand même cool que ça marche, et en vrai c’est bien l’essentiel ;)

Bonus : Erreur insserv: FATAL: service corosync has to be enabled

Si vous rencontrez l’erreur suivante :

insserv: FATAL: service corosync has to be enabled to use service corosync-qdevice

Allez supprimer le fichier d’init SysV corosync sur tous les hôtes

rm /etc/init.d/corosync-qdevice
systemctl enable corosync-qdevice
systemctl start corosync-qdevice

Source : https://forum.proxmox.com/threads/setting-up-qdevice-fails.56061/

Cet article Un cluster Proxmox VE avec seulement 2 machines ! est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/10/11/un-cluster-proxmox-ve-avec-seulement-2-machines/feed/ 0 5136
Racisme, misogynie, et pire encore… beaucoup de boulot pour nettoyer l’IT https://blog.zwindler.fr/2019/09/17/racisme-misogynie-et-pire-encore-beaucoup-de-boulot-pour-nettoyer-lit/ https://blog.zwindler.fr/2019/09/17/racisme-misogynie-et-pire-encore-beaucoup-de-boulot-pour-nettoyer-lit/#comments Tue, 17 Sep 2019 16:00:52 +0000 https://blog.zwindler.fr/?p=5151 Richard Stallman démissionne de la présidence de la FSF 💥 BOOM ! 💥 C’est la news (qu’on suspectait arriver, certes)

Cet article Racisme, misogynie, et pire encore… beaucoup de boulot pour nettoyer l’IT est apparu en premier sur Zwindler's Reflection.

]]>
Richard Stallman démissionne de la présidence de la FSF

💥 BOOM ! 💥

C’est la news (qu’on suspectait arriver, certes) de mardi matin, dans le petit monde de l’IT et plus particulièrement du logiciel libre.

https://www.fsf.org/news/richard-m-stallman-resigns

Richard « RMS » Stallman, sous la pression, démissionne de la présidence de la FSF (Free Software Foundation).

C’est pourtant lui qui l’avait fondée fin 85, dans le but de promouvoir les logiciels libres.

Pour beaucoup, RMS est/était un mentor. Une vie passée à défendre les 4 libertés fondamentales du logiciel libre, forcément, ça laisse des traces.

Une démission inévitable

Qu’est ce qui a « mis le feu au poudre » ?

Depuis quelques jours, de nombreuses personnes réclamaient la démission de Richard Stallman suite à une série d’emails, envoyés sur une large mailing liste du MIT (université dans laquelle RMS est également ). Ces emails ont été révélés par une élève du MIT (Selam Jie Gano), dans un post publié sur Medium qui est quasiment instantanément devenu viral.

Pour ceux qui n’ont pas suivi, Stallman a publiquement défendu un de ses anciens collègues, Marvin Minsky. Sa thèse étant que Epstein a forcé une étudiante du MIT mineure à approcher Minsky, mais que Minsky n’aurait pas su qu’elle n’était pas consentante… Glauque…

We can imagine many scenarios, but the most plausible scenario is that she presented herself to him as entirely willing. Assuming she was being coerced by Epstein, he would have had every reason to tell her to conceal that from most of his associates.

Richard Stallman dans un email envoyé à des collègues et des élèves du MIT

Dans le meilleur des cas, Richard Stallman est juste extrêmement maladroit. Dans le pire…

Difficile de trancher avec certitude, même avec tous les éléments qui sont remontés depuis, mais le passé de Richard Stallman ne l’a sûrement pas servi dans cette histoire. La déferlante médiatique a choisi « le pire », conduisant à son inévitable démission.

Car en réalité, cela fait des années que RMS enchaîne les propos polémiques de ce goût là. Plusieurs articles de blogs ont remontés les nombreuses sorties de RMS (blog/emails), jusqu’à 2006 et clairement ça donne la gerbe.

I am skeptical of the claim that voluntarily pedophilia harms children. The arguments that it causes harm seem to be based on cases which aren’t voluntary, which are then stretched by parents who are horrified by the idea that their little baby is maturing.

–Richard Stallman en 2006

Et encore, si c’était le seul ?

Vous allez me dire « OK, c’est peut-être un sale type, et si c’est le cas, bon débarras ».

Le souci, c’est que Richard Stallman n’est qu’un exemple de ce qui ne va pas dans l’informatique, et plus largement dans notre société.

Je ne compte plus le nombre de commentaires/d’histoires sexistes, misogynes, racistes ou homophobes que j’ai entendu dans notre environnement au sens large (cercles pro, réseaux sociaux, presse, …).

Et ce que je trouve le plus inquiétant dans tout ça, c’est peut être que finalement, on est pas (peu) au courant, à moins d’explicitement chercher ce genre de choses. C’est comme si tout le monde s’en fichait.

Au même titre que je n’apprend que maintenant les opinions publiques de RMS, la semaine dernière, je découvrais avec stupeur que l’auteur de Dilbert (web comic d’un sysadmin), que j’aimais bien, est en réalité un raciste misogyne, ouvertement assumé, depuis des années.

Comment est ce que j’ai pu passer à côté de ça ? Est ce qu’on est à ce point dans notre microcosme technico-technique au point de tout passer à ce genre de personnes ?

Dans un registre différent, Linus Torvalds, le créateur de Linux, est spécialement connu pour son agressivité et sa grossièreté en public, notamment sur la mailing list du noyau Linux :

“Please just kill yourself now. The world will be a better place”

“Guys, this is not a dick-sucking contest”

“SHUT THE FUCK UP!”

— Linus Torvalds

Est ce qu’on a vraiment envie de travailler dans un domaine où on laisse ce genre de personnalités toxiques s’exprimer sans mot-dire ?

Ces gens là sont quand même hyper influents !

Je le redis, pour beaucoup ces gens là sont des mentors, des maîtres à penser. Et donc on les laisse faire…

Alors dans ces conditions, est ce que finalement, sil y a aussi peu de femmes influentes dans la Tech, est ce que c’est vraiment surprenant ?

Dans un monde où un conseiller inconnu de tous sans aucune compétence, qu’on a chargé shortlister une Secrétaire d’état au numérique parmi 4 femmes archis connues et influentes dans la Tech, préfère s’autoproclamer ?

Il a même applaudi des deux mains par la presse spécialisée !

Qu’est ce qu’on peut y faire ?

Après tout, c’est vrai, tous ces problèmes sont des problèmes de société. Dire que cela vient uniquement de l’informatique serait très exagéré.

Pour autant, je suis convaincu qu’on peut tous faire quelque chose pour aller dans le bon sens, notamment dans l’informatique.

Une étape qui ne coute rien : je vais arrêter de parler de ces gens là dans mes talks. Mine de rien, arrêter d’ériger ces gens là en modèle, c’est déjà un premier pas.

Et ensuite, si vous voulez d’autres pistes, vous pouvez (re)écouter le talk d’ouverture de BDX.IO 2018 d’Audrey Neveu – The Hitchhiker’s Guide to Diversity (Don’t panic!) :

Avec un peu d’huile de coude, on devrait réussir à faire bouger le choses.

Cet article Racisme, misogynie, et pire encore… beaucoup de boulot pour nettoyer l’IT est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/09/17/racisme-misogynie-et-pire-encore-beaucoup-de-boulot-pour-nettoyer-lit/feed/ 11 5151