Zwindler's Reflection https://blog.zwindler.fr Ma vie parmi les lol-cats || je mine des bitcoins dans mon dressing Sun, 10 Nov 2019 16:10:01 +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 [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
Du Ceph dans mon Kubernetes https://blog.zwindler.fr/2019/09/10/du-ceph-dans-mon-kubernetes/ https://blog.zwindler.fr/2019/09/10/du-ceph-dans-mon-kubernetes/#comments Tue, 10 Sep 2019 06:45:22 +0000 https://blog.zwindler.fr/?p=5141 Tutoriel pour installer simplement un cluster Ceph sur un cluster Kubernetes en utilisant Rook

Cet article Du Ceph dans mon Kubernetes est apparu en premier sur Zwindler's Reflection.

]]>

Un cluster Ceph dans mon K8s

Make Stateful K8s Great Again

La semaine dernière, j’ai partagé mon sentiment sur le fait qu’il y a un intérêt à utiliser (dans certains cas) Kubernetes. Particulièrement dans le cas d’une infrastructure micro-services fortement hétérogène !

Cependant, certains pourraient être tentés de me faire remarquer que cette infrastructure logicielle a été conçue pour être stateless (l’ensemble des états étant stockés à part, dans une base de données externalisées). Et ainsi, elle s’intègre facilement dans Kubernetes (on se mord la queue).

C’est vrai, en partie. Kubernetes simplifie VRAIMENT la vie dans un contexte comme celui ci. Pour autant, ça ne veut pas dire non plus qu’il n’est pas possible (ni même complexe) de faire du stateful avec Kubernetes.

D’ailleurs, un de mes premiers articles sur Kube en parlait, puisque j’avais PoCé (PoCqué ? que c’est moche parfois le Franglais…) le stateful sur K8s avec XWiki, début 2018. Dans cet article, j’avais créé un instance XWiki + PostgreSQL avec du stockage hautement disponible via GlusterFS, installé directement SUR les machines K8s.

Et Ceph dans tout ça ?

Ceph, c’est une autre paire de manches. D’abord, c’est du stockage bloc en mode synchrone (alors que GlusterFS est un FS distribué). C’est donc pas du tout la même chose.

Thanks captain obvious

Ensuite, c’est quand même un poil plus compliqué à installer et configurer. GlusterFR on se contente d’un démon (ou deux) et de connecter les nœuds entre eux puis déclarer des briques. Sur Ceph, en revanche, il existe plusieurs notions complémentaires (les OSD, les moniteurs, les managers, …).

Une fois de plus, je ne dis pas que ça serait compliqué à faire dans K8s, mais bon… pourquoi s’embêter ?

Et donc Rook ?

Pourquoi s’embêter alors qu’un projet intégré à la CNCF prend en charge l’abstraction de Ceph (et d’autre) directement comme des ressources de Kubernetes ?

A Storage Orchestrator for Kubernetes Rook turns distributed storage systems into self-managing, self-scaling, self-healing storage services. It automates the tasks of a storage administrator: deployment, bootstrapping, configuration, provisioning, scaling, upgrading, migration, disaster recovery, monitoring, and resource management.

Grosso modo, Rook nous automatise la gestion de stockage hautement disponible, en gérant le stockage comme une ressource dans Kubernetes.

Dans ce tuto, je vous propose donc de se concentrer sur Ceph uniquement, mais vous pouvez très bien déployer autre chose (en suivant la doc).

Sachez que Ceph vient de passer en V1 dans le projet Rook, signe de stabilité. Cependant, vous avez plein d’autres options (Cassandra, Minio, …) à divers niveaux de maturité dans leur intégrations avec le projet Rook.

Prérequis

D’abord les prérequis => https://rook.github.io/docs/rook/v1.0/k8s-pre-reqs.html.

Rook est disponible depuis un moment, mais si vous voulez vous évité des soucis, il est conseillé de rester sur une version relativement récente de Kubernetes. Rook est officiellement supporté sur les K8s 1.10+.

Il vous faudra un compte avec les prévilèges cluster-admin pour bootstrapper Rook. Ne vous inquiétez pas, c’est juste le temps de créer les rôles et les CRDs.

Si vous n’en possédez pas, il est possible de demander à votre admin préféré de configurer directement les bons droits pour Rook à la main (https://rook.github.io/docs/rook/v1.0/psp.html).

Enfin, il sera nécessaire d’avoir sur les machines qui exécutent Rook+Ceph de disposer du module Kernel rbd et d’avoir le package lvm2 d’installé.

modprobe rbd

Ne doit rien retourner.

If it says ‘not found’, you may have to rebuild your kernel or choose a different Linux distribution.

On déploie Rook et Ceph !

Rook nous met à disposition des fichiers d’exemples sur le dépôt principal, notamment pour configurer Ceph de A à Z :

git clone https://github.com/rook/rook.git
cd rook/cluster/examples/kubernetes/ceph
kubectl create -f common.yaml
kubectl create -f operator.yaml
kubectl create -f cluster-test.yaml

Le fichier common.yaml va créer les CRD nécessaires à Rook, les (Cluster)Roles, les services accounts et enfin les (Cluster)RoleBindings associés.

Le fichier operator.yaml créé un déploiement rook-ceph-operator, qui va nous permettre de gérer les demandes de créations de CRD de Rook (lien vers un tuto pour expliquer ce que sont les CRD et les operators)

Le dernier fichier, cluster-test.yaml est celui qui va réellement créer le cluster Ceph dans votre Kubernetes. C’est lui qui va déterminer le nombre de chaque composant de Ceph dont vous aller disposer.

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: ceph/ceph:v14.2.2-20190722
    allowUnsupported: true
  dataDirHostPath: /var/lib/rook
  mon:
    count: 1
    allowMultiplePerNode: true
  dashboard:
    enabled: true
  monitoring:
    enabled: false  # requires Prometheus to be pre-installed
    rulesNamespace: rook-ceph
  network:
    hostNetwork: false
  rbdMirroring:
    workers: 0
  storage:
    useAllNodes: true
    useAllDevices: false
    directories:
    - path: /var/lib/rook

Note: Dans mon cas, j’ai ajouté à mes machines un disques /dev/sdd; j’ai donc remplacé les dernières lignes par "deviceFilter: sdd"

Une fois que vous avez exécuté la dernière commande, vous avez un cluster Ceph "de démo" opérationnel.

Il n’est pas conseillé de l’utiliser tel quel en production, car plusieurs composants ne sont pas redondés comme on a pu le voir en lisant le YAML ci dessus, et le stockage est assuré par un dossier sur chaque hôte Kubernetes, ce qui n’est pas du tout conseillé.

Cependant, on a l’ensemble des features qui sont activées, c’est parfait pour un test (mode bloc, objet ou fichier)

Vérifier que tout fonctionne

La documentation de Ceph recommande d’utiliser un déploiement appelé rook-toolbox pour vérifier que tout fonctionne.

Dans un premier temps, on peut commencer par simplement regarder si tous nos pods sont vivants :

kubectl --namespace=rook-ceph get pods
NAME                                                   READY   STATUS      RESTARTS   AGE
csi-cephfsplugin-5r648                                 2/2     Running     0          2d22h
csi-cephfsplugin-provisioner-0                         3/3     Running     0          2d22h
csi-rbdplugin-m7299                                    2/2     Running     0          2d22h
csi-rbdplugin-provisioner-0                            4/4     Running     0          2d22h
rook-ceph-agent-b79dl                                  1/1     Running     0          2d22h
rook-ceph-mgr-a-86586f9f4d-lz5df                       1/1     Running     0          2d22h
rook-ceph-mon-a-5fdc888bc4-qqb4m                       1/1     Running     0          2d22h
rook-ceph-operator-698b5d4fcc-dwdth                    1/1     Running     6          2d22h
rook-ceph-osd-0-667dcd84cf-h2tz8                       1/1     Running     0          2d22h
rook-ceph-osd-prepare-aks-agentpool-12737853-0-ntrn5   0/2     Completed   0          5h26m
rook-discover-sfdj4                                    1/1     Running     0          2d22h

Comme on peut le voir, tout est OK dans mon exemple.

On peut ensuite déployer la toolbox, dont le fichier YAML est présent dans le même dossier :

kubectl create -f toolbox.yaml

kubectl -n rook-ceph exec -it $(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" -o jsonpath='{.items[0].metadata.name}') bash

Une fois connecté, on peut lancer les commandes suivantes et commencer à interagir avec Ceph

ceph status
  cluster:
    id:     7099fc42-a47f-4412-8775-f6f3d4ce669d
    health: HEALTH_OK
 
  services:
    mon: 1 daemons, quorum a (age 111s)
    mgr: a(active, since 78s)
    osd: 1 osds: 1 up (since 60s), 1 in (since 60s)
 
  data:
    pools:   0 pools, 0 pgs
    objects: 0 objects, 0 B
    usage:   12 GiB used, 84 GiB / 97 GiB avail
    pgs:   


ceph osd status
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+
| id |           host           |  used | avail | wr ops | wr data | rd ops | rd data |   state   |
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+
| 0  | aks-agentpool-12737853-0 | 12.4G | 84.4G |    0   |     0   |    0   |     0   | exists,up |
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+

Créer un pool Ceph

Dans cet exemple, comme je n’ai qu’un seul OSD (un seul "disque", ici un dossier sur un serveur), je vais créer un pool sans réplication.

Si vous utilisez Rook en Production, vous aurez donc vous des disques dédiés (au minimum un sur tous les serveurs, ou à minima, au moins 3). Voir la documentation officielle pour plus d’info.

---
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: replicapool
  namespace: rook-ceph
spec:
  failureDomain: host
  replicated:
    size: 1

De même, on va créer une StorageClass, qui va permettre à Kubernetes de réaliser la création des volumes à la demande (les PVs sont créés lorsqu’une application demande la création d’un volume via un Persistent Volume Claim)

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: rook-ceph-block
provisioner: ceph.rook.io/block
parameters:
  blockPool: replicapool
  clusterNamespace: rook-ceph
  fstype: xfs
reclaimPolicy: Retain

A partir de là, vous avez maintenant un stockage hautement disponible et réparti équitablement sur vos serveurs Kubernetes.

Si vous voulez tester, dans le même dépôt, on a à disposition 2 fichiers YAML d’exemple pour déployer MySQL + WordPress

zwindler:~/sources/rook/cluster/examples/kubernetes$ kubectl create -f mysql.yaml
service/wordpress-mysql created
persistentvolumeclaim/mysql-pv-claim created
deployment.apps/wordpress-mysql created

zwindler:~/sources/rook/cluster/examples/kubernetes$ kubectl get pvc
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
mysql-pv-claim   Bound    pvc-d245dd2d-d0a1-11e9-9f5c-26f444bf7bdc   20Gi       RWO            rook-ceph-block   10s

zwindler:~/sources/rook/cluster/examples/kubernetes$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                    STORAGECLASS      REASON   AGE
pvc-d245dd2d-d0a1-11e9-9f5c-26f444bf7bdc   20Gi       RWO            Retain           Bound    default/mysql-pv-claim   rook-ceph-block            26s

Elle est pas belle là vie :) ?

Cet article Du Ceph dans mon Kubernetes est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/09/10/du-ceph-dans-mon-kubernetes/feed/ 5 5141
Concerning Kubernetes : « combien de problèmes ces stacks ont générés ? » https://blog.zwindler.fr/2019/09/03/concerning-kubernetes-combien-de-problemes-ces-stacks-ont-generes/ https://blog.zwindler.fr/2019/09/03/concerning-kubernetes-combien-de-problemes-ces-stacks-ont-generes/#comments Tue, 03 Sep 2019 06:30:16 +0000 https://blog.zwindler.fr/?p=5068 Billet d'humeur pour parler de tout ces gens qui considèrent que Kubernetes apporte plus de problèmes qu'il n'en résout

Cet article Concerning Kubernetes : « combien de problèmes ces stacks ont générés ? » est apparu en premier sur Zwindler's Reflection.

]]>

La hype, c’est de dire que Kubernetes c’est nul (parce que c’est hype ?)

Youpi ! Encore un billet d’humeur cette année ;-)

J’espère que comme moi, quand vous lisez dans votre tête "Concerning Kubernetes", vous avez l’air de "Concerning Hobbits" de Howard Shore dans la tête :)

Aujourd’hui je vais parler de Kubernetes mais rien de technique, seulement un question que je me pose :

Pourquoi c’est devenu à la mode de dire que Kubernetes c’est pas bien ?

Alors forcément, en "full disclosure", pour ceux qui ne me connaissent pas, je suis obligé d’indiquer que j’utilise Kubernetes dans mon travail d’Ops depuis environ 2 ans (++). J’en ai d’ailleurs abondamment parlé ces deux dernières années.

J’ai également utilisé Kubernetes à titre personnel pendant 6 mois, notamment pour héberger mon blog. L’objectif était uniquement d’apprendre Kubernetes par l’usage et je n’ai à aucun moment considéré que ce mode d’hébergement convenait à mes besoins (d’ailleurs, je ne l’utilise plus à titre personnel, maintenant que je sais comment ça marche).

Car oui, Kubernetes c’est un outil

Et comme tout outil, il faut :

  • l’utiliser idéalement dans les cas qui correspondent à son usage
  • savoir l’utiliser
File source: https://commons.wikimedia.org/wiki/File:Sledgehammer_(3586724830).jpg

Et donc, le cœur du sujet ?

Donc je l’ai déjà dis, mais ça fait quelques semaines que je vois de nombreuses attaques de personnes différentes qui expliquent que Kubernetes, c’est naze.

J’ai classé ces personnes en 4 types d’intervenants sur le sujet.

1, des Ops

D’abord, des confrères. La plupart du temps, il s’agit de gens qui n’ont pas utilisé l’outil, ne travaillent pas dans des environnements où Kubernetes pourrait rapidement leur apporter des gains, ou qui n’ont juste pas envie de changer leurs habitudes.

Oui, Kubernetes c’est (modérément) complexe. Même Kelsey Hightower, évangeliste Kubernetes niveau super Rockstar de chez GCP (Google) et auteur du guide "Kubernetes the hard way" le clame haut et fort :

Utiliser Kubernetes impose d’assimiler un certain nombre de concepts techniques, pour une part inhérents aux architectures microservices containerisées, pour l’autre part spécifiques à Kubernetes lui-même. De même, il faut composer avec un certain nombre de limitations et accepter de travailler différemment (on ne gère pas un serveur web de la même façon dans une VM et dans un container sur un orchestrateur managé).

Autant dire que quand un confrère Ops me parle de passer directement d’un environnement bien massif de type IBM AIX et ERP propriétaire vers l’installation d’un Openshift, la première chose que je lui dis c’est "Tu es sûr ? Tu ne veux pas plutôt tester un peu les containers Docker d’abord ?".

Dans des cas comme ça, échouer puis reprocher à Kubernetes d’être complexe est un peu malhonnête. Car quand on passe directement d’un mainframe à Kubernetes, on a loupé plusieurs changements dans la façon de travailler dans l’IT de ces 10 dernières années (++).

2, des hobbyists

Quasiment à chaque fois que j’écris un article sur Kubernetes, même quand il s’agit d’un truc aussi simple à déployer que l’offre Kubernetes as a Service d’OVH, je me retrouve avec un commentaire du style

Alors, déjà merci, parce que ça me fait toujours sourire ce genre de commentaires sur le blog ;-)

Ensuite : mais par rapport à quoi ?

  • A héberger tes photos de vacances sur ton NAS Synology ? Certainement !
  • A gérer une plateforme de domotique sur ton raspberry pi ? Sans aucun doute.
  • A publier tes 3 billets de blog sur Medium ?

Là c’est déjà un peu plus contestable, sachant que tu ne sais pas comment Medium fait pour obtenir un site web utilisé par un grand nombre d’auteurs et de lecteurs, résilient, accessible worldwide et sans plage de maintenance.

Le bon outil

Vous vous souvenez, au début de l’article, la métaphore de la mouche et du sledgehammer ? Bah on est en plein dedans là.

Bien sûr, utiliser Kubernetes pour toutes ces choses n’a pas de sens (publier 3 posts persos lu par 1000 personnes par jour et gérer ta domotique), en tant que particulier.

Ça me rappelle beaucoup le débat qu’il y avait eu lorsqu’un transformateur RTE avait brûlé en juillet 2018 et que la gare Montparnasse avait été dans le noir pendant des heures.

Tout le monde a hurlé au scandale ("pourquoi vous n’avez pas redondé le truc ???") et des types sont venus nous dire sur Twitter "nianiania arrêtez de dire que c’est pas normal de pas redonder. Est ce que vous avez 2 frigos chez vous, au cas où l’un d’entre eux tombe en panne ?"

Je pense que n’importe qui d’un peu honnête peut convenir que des outils d’entreprises comme Kubernetes répondent à des problématiques qu’on ne va pas avoir à gérer quand on est un particulier… Au même titre qu’on peut se permettre de n’avoir qu’un seul réfrigérateur chez soit.

Note : pour ceux qui n’ont pas suivi, dans le cas précis de Montparnasse en 2018, c’était la faute de RTE qui avait garanti à la SNCF que les 3 entrées électriques provenaient de 3 sources différentes, alors que c’était faux.

La 3ème catégorie

Ça fait titre de SF ce sous titre, non ? Ok, je sors => []

Dans les gens qui bashent le plus Kubernetes, on retrouve sans trop de surprise les gens dont le business est en concurrence plus ou moins directe avec Kubernetes. Et naturellement, ce sont eux qui font le plus de bruits (relayés par les autres).

Attention, je ne nie pas le fait que ces gens brillants (s’ils ont réussi, ce n’est pas pour rien) et que leur analyse est pertinente sur certains points.

Pour autant, on peut généralement trouver sans trop de difficultés une certaine mauvaise foi quand ils parlent de Kubernetes (que ce soit conscient ou pas)…

Quand Ian Eyberg écrit "Kubernetes is in Hospice" sur LinkedIn, on peut se demander s’il ne devrait pas demander à quelqu’un de le relire avant d’appuyer sur la touche entrée…

Je vous passe la grossièreté ("crap", etc), le mépris gratuit pour les "développeurs lambda qui font du JS parce que c’est plus simple"… Un type charmant, comme vous pouvez le voir.

k8s est juste une tentative de Google pour faire venir les gens sur Google Cloud

Tu la sens venir la théorie du complot reptilien ?

Facebook n’utilise pas Kubernetes car ça ne scale pas assez bien pour eux. Votre startup de 20 personnes ne devrait pas l’utiliser non plus.

Comparer les besoins de Facebook avec les besoins d’une startup de 20 personnes est une choix intéressant, en terme d’argumentaire je trouve. Et entre la startup et les GAFA, il n’y a rien d’autre ?

La sécurité dans les containers est un échec total

Parce que bien sûr la sécurité dans l’IT non containerisée est totalement maîtrisée. Il n’y a pas du tout d’exploits pour sortir d’une VM, les OS sont toujours à jour chez tout le monde, l’IOT c’est Fort Knox.

(Vous me connaissez, je vous ai forcément gardé le meilleur pour la fin )

Le site https://k8s.af est une collection d’histoires d’horreur sur la façon dont des sociétés ont échoué avec kubernetes. Ce n’est pas quelque chose qu’il faut applaudir ou dont il faut apprendre; c’est quelque chose à éviter. Vous ne pouvez pas dire que vous être ingénieur en génie civil et construire un pont qui risque de s’effondrer. Il y a des vies en jeu !!!!1!1!111

Est ce qu’on peut expliquer à ce monsieur que des fois des ponts s’écroulent et que JUSTEMENT, c’est parce qu’on essaye d’éviter que ça se reproduise qu’on apprend de nos erreurs et qu’on évite de les réitérer ?

Une réponse de l’auteur de k8s.af à ce genre de personnes

Bon, une fois qu’on a lu tout ça, on prend une grande inspiration, on regarde l’entreprise que dirige Ian Eyberg et on voit qu’il est PDG de … NanoVMs.

Et au cas où vous doutiez encore un peu, NanoVMs est une société qui se positionne ouvertement comme une alternative à Docker.

Business is business.

Et les fournisseurs de service ?

Dans le même genre, je me suis pris la tête avec le fondateur d’une solution cloud qui propose aux Dev de gérer l’Ops pour eux, pour qu’ils se concentrent sur le Dev (business totalement pertinent et louable). Il vend un service bien marketé, UX bien pensée, etc, rien à redire de ce côté là.

Cette personne m’explique que c’est plus simple pour un Dev d’utiliser son service que quand je demande à mes collègues Dev d’écrire un template Helm (on y reviendra). Soit, je veux bien l’entendre.

Mais derrière, s’il n’utilise pas Kubernetes (probable vu l’opinion qu’il a de l’outil), il a forcément du déployer des stacks techniques pour résoudre les problématiques similaires (déploiement, provisionning, haute dispo, répartition de charge). Donc au final, il a juste implémenté d’une autre façon, quelque chose qui fait comme Kubernetes.

Et quand je lui fais remarqué ce point précis, devinez ce qu’il m’a répondu (avec les majuscules et tout) ?

RIEN A VOIR

Donc quoi ? Tu fais tout à la main ?

Je vous jure, des fois, la mauvais foi des gens me fatigue…

4, des devs

Et là, on tombe sur la catégorie de personnes dont les réactions négatives m’attristent le plus.

J’ai l’impression que ces gens là ne se rendent pas trop compte de l’effort qu’il faudrait déployer pour obtenir la même chose, sans Kubernetes.

En fait, c’est comme si, en rendant le service aussi résilient qu’il l’est devenu, les Devs pensent que c’est simple d’avoir aussi bien, sans Kubernetes (remplacez Kubernetes par tout autre outil permettant d’automatiser la gestion d’une infrastructure complexe et hétérogène).

Un peu plus de détails

Dans mon travail, nous hébergeons plusieurs plateformes Kubernetes. Ces plateformes sont à destinations des développeurs, pour leur fournir de l’infrastructure de manière "masquée", managée par nous.

Pour vous donner un ordre de grandeur, on parle d’une demi douzaine de clusters, avec entre 50 et 100 machines virtuelles, qui font tourner de manière résiliente plusieurs centaines d’applications chacun.

Ces applications (types microservices) sont hautement hétérogènes. On y dénombre pas moins de 5 ou 6 langages de programmation différents, deux ou trois fois plus de frameworks, des messages bus, des bases de données externes, …

Avec Kubernetes, nous ne leur demandons pas de gérer l’infra, ni même de nous demander de l’infra. Nous leur fournissons, au travers d’une chaîne d’intégration continue (IC), un self service pour consommer cette infrastructure. Les seules choses qu’on leur demande pour consommer cette infrastructure, c’est :

  • de créer leur propre image (aka "image Docker")
  • de rédiger les spécifications de leur application, interprétables par Kubernetes (via Helm, le langage de templating le plus répandu pour déployer sur Kubernetes)
Un extrait d’un chart Helm (https://github.com/helm/charts/blob/master/stable/bitcoind/templates/deployment.yaml)

Pour ces choses, ils peuvent se baser sur des exemples de projets existants et/ou demander de l’aide à mes collègues Ops ou mes collègues de l’intégration continue.

Hashtag DevOps.

Ces deux choses qu’on leur demande sont donc ni plus ni moins que de la configuration et un genre de "code" simpliste, au même titre qu’ils renseignent déjà un pom.xml ou autre packages.json. Pour un développeur, on peut s’attendre à ce que ça ne soit pas un souci.

Et que gagnent ils en échange de ce travail ?

De l’autonomie, du temps

Surtout de l’autonomie sur le déploiement de nouvelles applications, au sens large du terme.

D’abord, pas besoin d’avoir un Ops pour aider et manipuler des problématiques complexes de configuration de serveurs, la redondance/haute disponibilité, répartition de charge, …

Tout ce qu’ils ont besoin de faire, c’est remplir un fichier texte YAML (certes très verbeux) avec les caractéristiques qu’ils souhaitent pour leur application (donne moi 3 instances identiques de telle container, avec tant de CPU/RAM). De base, l’application est alors déployée de manière reproductible, résiliente, se régule d’elle même en cas d’incident, …

Pas besoin de demander aux OPS une nouvelle paire de serveurs webs à la moindre modif et surtout… pas besoin d’attendre pour l’avoir !!

"Le futur et toutes les raisons d’y croire"

Pour illustrer, je peux vous parler d’un exemple personnel. Dans une autre vie pas si lointaine, j’ai été OPS pour un grand opérateur. Pour chaque nouveau projet, je recevais des demandes (aka. un ticket) de la part des Dev pour configurer des serveurs web. Mes collègues et moi avions 3 semaines pour traiter ces demandes.

TROIS… SEMAINES…

Autant dire que j’ai eu un paquet de fois à tout refaire car entre temps, un nouveau modèle (master) avec la mise à jour de l’application était sorti le temps que la demande d’environnement soit traitée.

Avec Kubernetes, en quelques secondes (5 minutes max si on compte toute la chaîne d’intégration continue), c’est livré.

Des Ops plus disponibles

De même, pour gérer ces plateformes, il faut X fois moins de gens pour les administrer que si on devait déployer ces serveurs à la main, à la demande, sur des VMs par exemple. A l’heure actuelle, côté Ops, 2 personnes suffiraient pour maintenir l’ensemble de ces clusters.

Je dis "suffiraient" car nous gérons beaucoup d’autres plateformes en plus de Kubernetes. En terme de "charge homme", 2 ETP auraient encore pas mal de marge pour absorber de nombreux projets (aka applications déployées) en plus. Les autres membres de l’équipe ont le temps de gérer d’autres plateformes.

Je n’ose pas imaginer le nombre d’Ops qu’il faudrait pour maintenir un équivalent "VM" contenant 250 applications hétérogènes, les loadbalancers, etc. 5 ? 10 ? 15 ? Bien plus que 2, c’est sûr…

Et ce temps que l’équipe Ops a de disponible, c’est du temps qui peut servir à améliorer l’infrastructure pour coller le mieux aux besoins des développeurs, maintenir les bonnes pratiques sur l’ensemble du périmètre, les assister en cas de bug, …

Faire du DevOps, en somme.

Moins d’incidents

Là, c’est LA partie qui devrait leur tenir le plus à cœur normalement.

J’ai travaillé sur tous types d’infrastructures. Des bons gros Mainframe, des infrastructures virtualisés, convergées, HYPERconvergées, des SAN, des NAS et depuis 2 ans, sur Kubernetes.

Et bien, laissez moi vous dire qu’il n’y a pas photo. Mais genre, pas du tout.

Le fait de travailler en microservices containerisés, en s’astreignant à suivre quelques bonnes pratiques, permet réellement d’obtenir un service de qualité. 95% des incidents, qu’ils viennent de plantages imprévus de l’application ou de problèmes sur l’infrastructure, se résolvent d’eux même en quelques secondes, la plupart du temps sans notification à l’astreinte lorsque ça n’est pas nécessaire (ce qui n’empêche de débugger a posteriori, juste pas en pleine nuit).

C’est extrêmement impressionnant.

Mes 6 derniers mois d’astreinte se résument quasiment exclusivement à des incidents sur la partie legacy et/ou non containerisée. La partie Kubernetes se gère toute seule, j’ai très rarement eu à intervenir, que ce soit sur la plateforme elle-même, ou sur les applications hébergées dessus.

Au final, les premiers fans de Kubernetes, ce sont les membres de ma famille, que je ne réveille plus la nuit pour redémarrer un serveur web ou basculer un cluster qui s’est mal déclenché.

Donc les devs sont contents ?

Et ben non…

Je ne compte plus le nombre de gens brillants qui m’ont dit :

nan mais attend ton truc, c’est super compliqué

le go template/YAML c’est incompréhensible

c’est pas mon job de faire ça

Et là, je suis hyper déçu.

Venant de gens qui sont capables de m’expliquer avec force de détails pendant 30 minutes ce qu’est une Monad, qu’un Monoid ce n’est du tout la même chose, je trouve ça culotté de venir m’expliquer qu’un bout de GOtemplate, c’est le summum de la complexité.

Je réitère une dernière fois… Oui, Kubernetes, c’est modérément complexe. Non, c’est pas trop complexe. Bien moins que tous les autres concepts que ces gens là manipules tous les jours. C’est juste que le DevOps, au fond, ça ne les intéressent pas vraiment.

Ça se résume d’ailleurs assez bien dans le "c’est pas mon job de faire ça".

C’est le job de qui alors ? De savoir ce que fait l’application, comment elle interagit avec les autres, de quelles ressources elle a besoin ?

Moi je dirais que c’est celui qui l’a développée, EN ÉQUIPE avec celui qui maintient l’infrastructure.

Et je conclurai mon propos par un petit tweet de @bitfield qui a fait pas mal sauter des Devs de leur chaise il y a 3 ans et qui n’a malheureusement pas pris une ride.

¯\_(ツ)_/¯

Cet article Concerning Kubernetes : « combien de problèmes ces stacks ont générés ? » est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/09/03/concerning-kubernetes-combien-de-problemes-ces-stacks-ont-generes/feed/ 12 5068
Cluster Proxmox VE, v6 cette fois ci ! https://blog.zwindler.fr/2019/08/20/cluster-proxmox-ve-v6-cette-fois-ci/ https://blog.zwindler.fr/2019/08/20/cluster-proxmox-ve-v6-cette-fois-ci/#comments Tue, 20 Aug 2019 11:45:00 +0000 https://blog.zwindler.fr/?p=5112 Tutoriel pas à pas (aidé de playbooks Ansible) pour déployer des clusters Proxmox VE 6 depuis des machines Debian Buster

Cet article Cluster Proxmox VE, v6 cette fois ci ! est apparu en premier sur Zwindler's Reflection.

]]>

Proxmox VE

Et oui, avec la sortie de Proxmox VE 6, je vous avais prévenu : il va y avoir pas mal d’articles là dessus, même si quelques articles sur Kubernetes sont en cours d’écriture aussi ;-).

Fin juillet, j’avais écris un article sur des playbooks Ansible que j’ai écris pour faciliter le déploiement de cluster Proxmox VE. Malheureusement, comme cet article traînait dans mes brouillons, les playbooks ne géraient pas la version 6 (qui venait de sortir) de PVE.

C’est aujourd’hui de l’histoire ancienne puisque, pour tester la v6, j’ai forcément du adapter les playbooks ;-).

Point important, je vais partir du principe que vous n’avez pas la possibilité d’installer Proxmox VE directement avec l’ISO. C’est souvent le cas souvent avec les hébergeurs de serveurs dédiés pas chers (oneprovider par exemple) ou de VMs (OVH, Scaleway, etc).

Car si vous avez la main, le plus simple est bien sûr d’installer l’ISO directement ! Cependant, ce tuto reste utile pour toute la partie mise en VPN et configuration du cluster.

Les prérequis

Dans l’article précédent, pour gagner du temps pour ceux qui veulent juste tester, j’avais mis à disposition un playbook permettant de générer des VMs chez le cloud provider Scaleway (et notamment tirer parti de l’inventaire dynamique proposé par le module développé par Scaleway pour Ansible).

Ici, je met volontairement de côté cette partie qui n’apporterait rien de plus. Si vous voulez voir comment ça fonctionne je vous invite à (re)lire l’article précédent, la procédure est la même.

Le seul prérequis pour ce tutoriel sont donc d’avoir idéalement 3 machines* (ou plus) sous Debian 10 (la raison pour laquelle je n’avais pas pu le faire avec Scaleway qui ne propose pas encore Debian Buster) accessibles en depuis votre station de travail.

*Mais si vous voulez juste installer Proxmox, une seule suffit mais vous n’aurez évidemment pas un cluster. A partir de 2, on peut faire un cluster mais il sera instable dès que vous perdrez une seule des 2 machines (ce qui est dommage) à moins d’ajouter un device pour permettre d’avoir le quorum (ce que nous verrons dans un autre article).

Installer Ansible et récupérer les playbooks

Des fois que n’auriez pas Ansible, installez le (pour git, c’est juste plus simple de cloner le dépôt mais vous pouvez le télécharger autrement si vous ne voulez pas installer git)

apt-get install git ansible
git clone https://github.com/zwindler/ansible-proxmoxve
cd 

Ensuite, on créé un fichier d’inventaire pour Ansible (ce qui n’étais pas nécessaire avec Scaleway puisque, je le rappelle, il y a un module d’inventaire dynamique). Ici on se contente juste de lister les serveurs qui nous intéressent.

cat pve_inventory.yml
all:
  children:
    proxmoxve:
      hosts:
        proxmox1.mydomain.tld:
        proxmox2.mydomain.tld:
        proxmox3.mydomain.tld:

Vous ne reconnaissez peut être pas le format de cet inventaire Ansible. En effet, l’inventaire est ici stocké au format YAML et non au format plat. Très peu de gens utilisent ce format (qui existait au début, puis a été retiré pour être de nouveau supporté depuis la 2.4 je crois).

Etant habitué aux inventaires parfois un peu hétéroclites, je préfère largement ce format YAML, qui permet de rajouter de manière beaucoup plus lisibles des varibles à des groupes ou mêmes des hôtes directement (sans passer par une arborescence complète avec groups_vars et hosts_vars). De plus, je trouve les dépendances entre groupes plus claires que lorsque nous avions à déclarer les :children du groupe père (mais c’est subjectif).

Notez par contre qu’il faut :

  • que mes hôtes soient résolvables par DNS (sinon il faut ajouter une variable ansible_host avec l’IP pour chacun)
  • que vous n’oubliez surtout par le ":" à la fin de chaque hostname, sans quoi vous aurez une erreur de syntaxe.

Lancer le playbook d’installation de Proxmox VE 6

Nous y voilà. Normalement vouspouvez accéder en SSH à l’ensemble de vos machines. Pour installer Proxmox VE 6 sur une debian 10, il faut donc simplement lancer la commande suivante :

ansible-playbook -i pve_inventory.yml proxmox_prerequisites.yml -u root

Normalement, le playbook vous promptera pour répondre à quelques questions basiques (votre domaine, est ce que les machines commencent par test plutôt que proxmox dans le hostname, …) et à l’issue, un reboot sera effectué (pour basculer sur le noyau Linux de PVE et pas celui de debian Buster).

Mise en réseau privé virtuel avec Tinc

Cette étape n’est pas forcément nécessaire. Si vous travaillez sur des machines qui sont dans un même réseau local, il vaut mieux s’en passer.

En revanche, dans le cas où comme moi vous louez des serveurs chez un provider et qu’il ne vous met pas à disposition un moyen de simuler un réseau privé (RPN chez Online, Rack quelque chose chez OVH je crois), il sera préférable de monter un VPN entre les différentes machines du cluster.

Je dis préférable et pas nécessaire, car jusqu’à la version 6 de Proxmox (et Corosync v3), il était nécessaire également de faire passer du multicast entre les machines pour faire fonctionner le cluster. Ce n’est aujourd’hui plus le cas et on peut donc très bien imaginer un cluster Proxmox avec des machines sur des LAN distincts. Cependant, pour activer des fonctionnalités comme Ceph (et probablement d’autre), il est toujours nécessaire d’avoir un LAN.

Pour se faire, j’utilise Tinc plutôt qu’OpenVPN, qui a l’avantage d’être simple à configurer et surtout multipoint (pas de notion de serveur maitre et de clients connectés dessus). Ce n’est pas le cas avec OpenVPN, dont la structure client/serveur complexifie beaucoup l’implémentation si on veut éviter un SPOF (en gros il faut un serveur sur toutes les machines, et que l’ensemble des serveurs soient tous clients les uns des autres, en toile d’araignée). Vous pouvez quand même jeter un oeil sur mes premières tentatives ici, si ça vous intéresse.

Comme j’automatise tout avec Ansible, j’ai donc aussi créé un playbook qui permet d’installer et configurer Tinc sur toutes nos machines et de les mettre en réseau sur un VPN dédié.

ansible-playbook -i pve_inventory.yml tinc_installation.yml -u root

A partir de là, vous avez donc 3 machines Proxmox VE 6, connectés ensembles sur un VPN avec l’adresse 10.10.10.0/24

Le réseau c’est compliqué ?

Un point pas forcément évident avec Proxmox est que la configuration du réseau dépend beaucoup de comment vos machines sont connectées en réseau.

Les différentes configurations conseillées sont détaillées dans un article dédié sur le wiki de Proxmox. J’aurais vraiment aimé connaître cette page lorsque M4vr0x et moi avons fait nos premières expériences avec PVE car nous avons beaucoup tâtonné…

Dans mon cas précis, j’ai des machines hostées par un provider. Je n’ai donc aucunement la main sur le réseau et je ne souhaite pas acheter d’IP supplémentaires.

Dans ce cas là, le plus simple est donc de créer un bridge Linux, qui portera un réseau virtuel interne à chaque serveur et dont le trafic externe sera routé.

L’inconvénient de cette solution est qu’on ne peut pas utiliser l’interface graphique pour faire ces modifications, et aussi qu’en cas d’erreur, vous n’aurez plus accès à votre serveur…

Configuration réseau pour des machines dédiées chez un Provider type OneProvider

Nous voilà donc dans les premières bidouilles manuelles. Connectez vous en SSH à votre (vos) serveurs, et modifier le fichier /etc/network/interfaces.

Je me suis basé sur la section "Masquerading (NAT) with iptables"

Le mien ressemble à ça :

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
#real IP address
iface eth0 inet static
        address  x.x.x.x
        netmask  24
        gateway  x.x x.1

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.1
        netmask 255.255.255.0
	bridge-ports none
	bridge-stp off
	bridge-fd 0

        post-up  echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE

Le plus important ici pour que tout fonctionne est que vous ne vous trompiez pas sur le nom de l’interface réseau (eth0 dans mon exemple).

Ensuite, une fois que les modifications sont faites, redémarrez le réseau (systemctl restart networking) ou carrément le serveur (c’est ce que Proxmox conseille, même si je ne vois pas bien l’intérêt).

Ici, la configuration est beaucoup plus simple que ce que nous avions imaginé avec M4vr0x dans la série d’articles détaillés sur PVE 5. Et c’est tant mieux car ça suffira amplement à la plupart d’entre vous ;-).

Configuration du cluster Proxmox VE

Ok ! Maintenant tous les prérequis sont en place, on peut donc construire le cluster. Le wizard de la GUI a assez peu évolué depuis la V5 (même s’il y a quelques petites améliorations)

  • Vous vous connectez sur une des machines
  • Dans la vue Datacenter, vous sélectionnez Create Cluster, puis vous copiez les informations de connexion pour les autres serveurs.
  • Sur les autres serveurs, vous rejoignez le cluster en collant les informations des

(Plus de détails dans l’article précédent)

Cet article Cluster Proxmox VE, v6 cette fois ci ! est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/08/20/cluster-proxmox-ve-v6-cette-fois-ci/feed/ 3 5112