Ça fait longtemps que zwindler n’a pas écrit un article sur Ansible ou XWiki !
Non ? Vous ne vous dites pas ça ? Bon tant pis c’est pas grave. Aujourd’hui, je rédige ENFIN l’article pour parler d’un playbook que j’ai déjà rédigé il y a presque un an déjà (et mis à jour et déployé de nombreuses fois). C’est dire si j’ai du retard dans les articles du blog…
Petit rappel des épisodes précédents
J’ai déjà rédigé de manière extensive sur XWiki qui est un belle solution open source de gestion de la connaissance. Parmi les articles les plus susceptibles d’intéresser, il y a déjà :
Et bien oui. Je vous rabâche aussi les oreilles avec Ansible, l’Infrastructure as Code, et l’Idempotence. (Là encore, il y en a plein)
Alors pourquoi pas un playbook Ansible pour automatiser l’installation de XWiki, si vous n’avez pas de cluster Kubernetes sous la main et que vous êtes un Gaulois réfractaire à Docker ?
Ce playbook a été testé pour des RHEL/CentOS 7, en particulier de la version 7.2 jusqu’à 7.4. Une installation de RHEL/CentOS en mode minimale, même sans environnement graphique, devrait être suffisante. Je l’ai faite tourner en production sur des environnements Desktop dans des VMs, mais aussi en Minimal sur un container LXC dans Proxmox VE sans aucun souci.
L’installation n’utilise pas les serveurs web et de bases de données par « défaut » (MySQL), mais Tomcat 8 et PostgreSQL. Pour la version de Tomcat, c’est une version très particulière qu’il faut utiliser car des bugs ont étés introduits dans une version, puis RE-introduits quelques mois plus tard. Vous pouvez modifier la version par défaut qui est une variables de mon playbook (8.5.32) si elle ne vous convient pas. Les instructions d’installation se basent sur la documentation officielle.
- tomcat_version: 8.5.32
Vous pouvez également modifier la version de XWiki directement dans le playbook (c’est une variable là aussi) :
- xwiki_version: "10.6.1"
A noter, les vielles versions de XWiki n’étaient pas hébergées sur le même dépôt, qui a changé récemment, d’où les deux URLs dans le playbook.
Prérequis
On va utiliser git pour récupérer le playbook et ansible (version de l’OS, rien d’exotique).
yum install ansible git
git clone https://github.com/zwindler/ansible-deploy-xwiki-tomcat-postgresql
cd ansible-deploy-xwiki-tomcat-postgresql
Le playbook devrait vous prompter pour un mot de passe pour l’utilisateur de base de données PostgreSQL, n’hésitez pas à mettre quelque chose de complexe. Vous ne devriez pas en avoir besoin.
Si vous avez une erreur qui vous dit que localhost est ignoré, vous pouvez l’ajouter à votre fichier d’inventaire global : /etc/ansible/hosts
sudo vim /etc/ansible/hosts
[local]
localhost ansible_connection=local
Et Paf ! Vous avez un XWiki installé, disponible à l’adresse http://votreIP:8080/. Il n’y a plus qu’à le configurer
Un bon moyen de commencer à bidouiller avec Kubernetes, c’est d’utiliser Minikube.
Pour ceux qui ne connaissent pas, il s’agit d’un script qui va récupérer une machine virtuelle préconfigurée avec tous les composants nécessaires à Kubernetes, et l’installer sur votre machine. Ce script est disponible sur Windows, Mac et Linux, et vous trouverez de nombreux tutos pour l’installer via le logiciel de virtualisation Virtual Box (à installer préalablement, en prérequis donc).
Mais admettons que vous ayez commencés à bidouiller avec Docker avec « Docker for Windows ». Quoi de plus normal de passer sur K8s (le petit nom de Kubernetes, plus court) après avoir joué avec Docker.
Et paf ! vous n’arrivez pas à installer, à cause d’un obscur message qui vous parle de Virtual Box (alors que vous ne l’utilisez pas). On coince dès les prérequis, ça commence mal.
Et oui… « Docker for Windows » active Hyper-V… et si Hyper-V est activé, impossible d’installer Virtual Box !
Si la plupart des tutoriels mettent en avant Virtual Box justement (car c’est l’option par défaut), vous n’avez peut être pas envie de désinstaller Docker for Windows pour autant !
Ou peut être que vous n’avez pas envie d’installer Virtual Box alors que votre Windows 10 vous fourni déjà « out of the box » un logiciel de virtualisation parfaitement valide (attention, je dis ça uniquement pour Windows 10, sur un PC client… Pour un serveur, c’est juste une grosse blague cette plateforme de virtu…).
On va quand même s’en sortir
En gros, on est censé dérouler simplement les prérequis : avoir VT-x/AMD-v d’activés dans le BIOS. Là je ne vais pas vous faire l’explication car ça dépend grandement de votre machine.
Ensuite, on ajoute la fonctionnalité Hyper-V sur votre Windows 10. Pour se faire, on ouvre le menu des « fonctionnalités Windows ».
Si ce n’est pas déjà fait cocher « Hyper-V », validez, et on vous demandera très probablement de redémarrer. Attention, à partir de là vous ne pourrez plus utiliser Virtual Box (c’est tout le but de cet article, mais bon) ou VMware player ou autre.
Et enfin, pour éviter des conflits avec Docker pour Windows, on va créer un réseau virtuel dédié dans notre console Hyper-V. Lancer le gestionnaire Hyper-V :
Sur le menu tout à droite, on créé un Commutateur virtuel dédié. Pour réaliser cette opération, on clique sur Gestionnaire de commutateur virtuel, puis dans la fenêtre qui s’ouvre, en haut à gauche dans la liste des Commutateurs virtuels, on clique sur Nouveau commutateur réseau virtuel.
Dans les propriétés, on lui donne un petit nom (minikube par exemple) et on oublie pas de cocher « Réseau externe » (pour utiliser une des cartes physiques comme un bridge) et de cocher ensuite « Autoriser le système d’exploitation de gestion à partager cette carte réseau (surtout si c’est votre seule carte réseau !).
Pour finir, on récupère Minikube ici et on lance la commande suivante depuis un Powershell :
Vous avez de la chance, tout se passe bien et vous avez Minikube d’installé sur votre poste. C’est la fête, vous allez pouvoir déployer des containers à Gogo !
PS D:\> minikube status
minikube: Running
cluster: Running
kubectl: Correctly Configured: pointing to minikube-vm at 172.16.25.173
Mais voici quelques protips supplémentaires spécialement dédiées aux spécificités de minikube.
Les Ingress !
Pour le fun, on va certainement vouloir ajouter le support des Ingress (pas activés par défaut) :
PS D:\> minikube addons enable ingress
ingress was successfully enabled
Accéder au dashboard
On peut accéder au Dashboard (l’interface web qui permet de contrôler k8s sans passer par kubectl ou les API) n’est pas directement accessible avec un kubectl proxy comme sur un Kubernetes standard.
Elle est cependant bien disponible sans ajout supplémentaire, à l’aide de la commande suivante :
minikube dashboard
Se loguer sur la machine virtuelle K8s
Si pour une raison ou pour une autre, vous voulez vous connecter en SSH sur la VM qui contient votre environnement Kubernetes, c’est possible ! Récupérez l’IP affectée à la VM (afficher avec un minikube status ou un kubectl config view).
Il existe un user « docker » avec pour mot de passe « tcuser » (mot de passe ultrasecure, s’il en est). A noter, ce compte à un accès sudo à la machine en NOPASSWD.
Ca peut être utile par exemple pour vérifier que les Adminission Controllers sont bien actifs (on en aura besoin dans un prochain article)
Et pour être parfaitement honnête, c’est ce qui m’est arrivé ! Du coup, je vous prépare un nouvel article avec toutes les astuces de troubleshooting. La suite — dans le prochain épisode, donc
Il y a deux semaines, j’ai fais un article sur l’installation de Minikube sur un poste Windows 10. Petite subtilité, l’article en question explique comment installer Minikube sur Hyper-V, nativement présent avec Windows 10, plutôt qu’avec Virtual Box, le choix par défaut mais qui nécessite un téléchargement et une installation complémentaire. Si vous l’avez loupé, c’est par ici.
Option 2 : Expectations meet life
On s’était arrêté dans l’article précédent à un monde merveilleux ou tout marche du premier coup.
Mais, vous vous en doutez, dans la vie (et particulièrement dans l’IT), rien ne se passe jamais comme prévu.
Voilà donc un petit florilège des problèmes que vous pourriez (ou avez) rencontrer (et leur résolution !)
VBoxManage not found
Si vous en venez à vous demander comment l’installer sur Hyper-V, c’est probablement que vous avez commencé par lancer la commande « minikube start » sans arguments… L’installeur a donc bêtement assumé que vous utilisiez Virtual Box (pourquoi ?) et vous vous retrouvez avec l’erreur suivante :
Error getting state for host: VBoxManage not found. Make sure VirtualBox is installed and VBoxManage is in the path.
Pourtant, vous avez beau forcer le start avec
--vm-driver hyperv
, rien y fait, ce n’est pas pris en compte.
Pour trouver comment résoudre ce problème, vous pouvez jeter à œil à cette issue sur github
En réalité, une fois le premier « start » lancé, les fichiers de configuration sont générés dans C:\users[votrelogin].minikube (et en particulier dans profiles\minikube\config.json).
Impossible d’expliquer à l’installeur que vous avez changé d’avis (oui oui…), il faut donc de supprimer tout le dossier .minikube et recommencer avec les bons paramètres la prochaine fois (enfin c’est le plus simple, on va dire).
minikube-v0.xx.x.iso: Le chemin d’accès spécifié est introuvable…
minikube-v0.28.1.iso: Le chemin d’accès spécifié est introuvable...
Ok, ça ne marche toujours pas. On passe en mode verbose pour avoir l’erreur exacte :
PS C:\windows\system32> minikube start --vm-driver hyperv --hyperv-virtual-switch "Primary Virtual Switch" -v=7
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
[...]
[stderr =====>] :
Downloading D:\Users\zwindler\.minikub\cache\boot2docker.iso from file://D:/Users/zwindler/.minikub/cache/iso/minikube-v0.28.1.iso...
E0906 15:10:27.568262 14484 start.go:174] Error starting host: Error creating host: Error executing step: Creating VM.: open /Users/zwindler/.minikub/cache/iso/minikub-v0.28.1.iso: Le chemin d’accès spécifié est introuvable..
Retrying.
E0906 15:10:27.873612 14484 start.go:180] Error starting host: Error creating host: Error executing step: Creating VM.
: open /Users/zwindler/.minikube/cache/iso/minikube-v0.28.1.iso: Le chemin d’accès spécifié est introuvable.
Pourtant le fichier existe. Et c’est reparti pour un tour sur Github pour avoir plus de détails !
Ici, c’est donc tout simplement le script Minikube qui ne sait pas que vous avez un disque D:\… Alors qu’il vient de le déposer lui même dans D:\ une ligne plus haut !!! La solution donc :
you can specify the path for the .minikub directory by setting the MINIKUBE_HOME env variable
Bon en vrai la bonne syntaxe sous Windows (dans Powershell en tout cas) c’est :
$MINIKUBE_HOME="D:\Users\[votrelogin]\"
On oublie pas de nettoyer la tentative précédente avec un :
minikube delete
FLMNH : « Error deleting machine profile config »
Si jamais en essayant de nettoyer votre environnement (pour recommencez, vous essayez un « minikube delete » et que vous vous prenez une erreur).
Rebelotte, on supprime le dossier D:\Users[votrelogin].minikube à la main.
Error starting host: Error starting stopped host: exit status 1
Tout à l’air de fonctionner. Vous croyez que vous vous en êtes sortis ? Pauvres fous
Au moment où tout se termine, le script vérifie que le cluster est opérationnel. Et après avoir boucler un moment : PAF !
Error starting host: Error starting stopped host: exit status 1
L’erreur n’est pas très explicite. En gros, vous êtes dans le cas où tout est bien installé, mais le curl pour vérifier que le cluster est UP échoue, pour un souci réseau. La plupart du temps, il s’agit de l’erreur suivante :
After some troubleshooting and head banging, it became apparent that the external network adapter had an ethernet adapter selected that was not connected to a network. (ethernet selected, instead of the wireless adapter). Of course an IP wont be allocated on an external network if none is connected.
Vérifiez donc dans les paramètres d’Hyper-V que vous ne vous êtes pas trompé d’adaptateur réseau lors de la configuration du réseau virtuel (cf l’article précédent) !
unable to authenticate, attempted methods [publickey none]
Ok, cette fois ci tout est censé être bon. Pourtant, à la fin, ça plante encore (désespoir).
Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [publickey none], no supported methods remain
Là je ne suis pas sûr à 100% ni de la cause, ni du fix, mais a priori, c’était un problème lié au client/serveur OpenSSH fourni par Microsoft, qui serait pourri. L’installation d’une autre version via Chocolatey semble avoir résolu le problème.
Hier soir, la dernière version d’Ansible (2.7) est sortie. Cette release s’est concentrée sur une amélioration de la performance et de la stabilité, même si de très nombreux modules ont fait leur apparition, comme à chaque nouvelle version.
Python
Le support de Python 2.6 est abandonné, au profit de Python 2.7. Cela signifie que l’hôte qui exécutera le playbook devra disposer de Python 2.7 au minimum (même si Python 2.6 est toujours supporté sur la machine cible).
Écritures concurrentes
Un problème auquel j’ai déjà eu affaire est la gestion des écritures concurrentes sur un même fichier (par exemple si plusieurs hôtes écrivent sur un même fichier distant ou alors un delegate_to). A priori il existe maintenant un « lock » pour éviter d’écraser les modifications. Il faudra que je teste pour voir si ça marche bien.
Performances accrues, généralisation du SSH pipelining ?
La plus grosse modification, qui va nécessiter des tests approfondis, est la modification de la manière dont sont déclenchées les actions/modules sur les serveurs distants. Précédemment, les tasks nécessitaient 2 commandes SSH au lieu d’une maintenant. Effectivement, le temps d’exécution de playbooks contenant des actions simple mais très nombreuses pouvait être très long.
Ansible-2.7 changes the Ansiballz strategy for running modules remotely so that invoking a module only needs to invoke python once per module on the remote machine instead of twice.
Un gain de performance dans ce genre de cas où on passe plus de temps à lancer des commandes que les exécuter est forcément une bonne nouvelle. Je me demande si ce n’est pas simplement une activation « par défaut » de la variable d’environnement ANSIBLE_SSH_PIPELINING=1 (que j’utilise déjà dans ce genre de cas).
A priori non si j’en crois cette issue, mais pour l’instant je n’ai pas remarqué de différence significative sur mes playbooks les plus gourmands en temps d’exécution.
Module reboot
A noter, la plupart des gens remontent l’arrivée d’un module « reboot » (et son équivalent « win_reboot ») qui redémarre une machine et ré-initie une connexion une fois que la machine a refait surface. Personnellement je n’utilise pas ce genre de fonctionnalité mais j’imagine que c’est une feature « nice to have » plutôt que d’utiliser le module « pause » ou la fonctionnalité « retry » en attendant que l’hôte refasse surface.
Les nouveaux modules
Je ne vais pas en faire la liste complète (disponible dans le changelog), mais cette version a visiblement été l’occasion pour les équipes de plusieurs cloud providers de se mettre en avant.
On peut noter les équipes de Google Cloud comme grands vainqueurs avec 39 nouveaux modules. Ils sont suivi par Azure (+21, avec l’apport des bases de données et des webapps), Vultr (13), et 8 pour Scaleway.
Tout ça m’intéresse beaucoup car, notamment pour Scaleway, de nombreux objets étaient encore indisponibles et il a fallut que j’écrive des scripts à la main pour curler l’API, ne serait ce que pour récupérer les IDs des templates de VMs que je voulais utiliser (impossible à lister autrement).
Maintenant, je peux sois l’exécuter à la main directement depuis Ansible, soit requêter le serveur Scaleway pour avoir une liste des images disponible directement dans mes playbooks :
ansible localhost -m scaleway_image_facts -a region=par1
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
localhost | SUCCESS => {
"ansible_facts": {
"scaleway_image_facts": [
{
"arch": "x86_64",
"creation_date": "2018-09-14T10:01:24.268850+00:00",
"default_bootscript": {
"architecture": "x86_64",
"bootcmdargs": "LINUX_COMMON scaleway boot=local nbd.max_part=16",
"default": false,
"dtb": "",
"id": "15fbd2f7-a0f9-412b-8502-6a44da8d98b8",
[...]
- name: Gather Scaleway images facts
scaleway_image_facts:
region: par1
register: images_facts
Et tant qu’on est dans le genre module qui vient remplacer des trucs que je faisais à la mimine, on peut aussi citer docker_swarm + docker_swarm_service pour gérer un cluster docker Swarm (comme son nom l’indique), ou k8s_facts pour récupérer des objets dans Kubernetes.
Et ma première contribution !
Même si j’ai déjà contribué sur plusieurs projets open source (traductions du site de Shinken, petites contributions à plusieurs plugins Nagios et à XWiki, ouverture d’issues dans de nombreux projects open source), j’ai également résolu ma première issue sur un gros projet grâce à Ansible et l’équipe d’Azure.
Il y a peu, Microsoft a mis à disposition sur Azure de machine virtuelle disposant gratuitement d’interface physique dédiées (non virtualisées donc) à 30 Gbps et avec une latence moindre (plus d’info sur la documentation officielle).
Au final, sur les 70 lignes de mon commit, il n’y a que 10 lignes de codes (le reste étant des tests et de la documentation, obligatoires pour toute soumission), mais je suis quand même content car ça marche bien
Encore un article qui traînait dans mon tiroir, depuis des mois ;-). Vous avez peut être suivi un de mes tutoriels pour installer Kubernetes, que ce soit avec kubeadm, kubespray, ou plus récemment avec Minikube. Vous avez peut être également lu le petit article que j’ai fais sur kubectx/kubens, pour se faciliter la gestion des contexts, quand on en a beaucoup.
Mais après avoir instancié un cluster et avant d’avoir à jongler entre plusieurs contextes, j’ai peut être zappé une (petite) étape entre les deux. Un détail, vraiment… il faut configurer les contextes en question !
La documentation officielle, si elle est riche et complète, a aussi l’inconvénient d’être assez troublante pour un néophyte, car il faut trier parmi plusieurs pages et une multitude de cas particuliers :
Authentification depuis l’arrivée du RBAC dans Kubernetes
Si vous suivez un peu Kubernetes, vous êtes peut être au courant d’une révolution qui est arrivée (et heureusement) dans l’administration des clusters Kubernetes. Depuis la version 1.7 (oui ce brouillon est en attente depuis la 1.7), on est passé du mode ABAC où les permissions des ServicesAccount étaient gérées dans un fichier de configuration et où les permissions étaient souvent très laxistes par défaut, à un mode RBAC (Role-based access control), bien plus riche et souvent mieux maîtrisé.
Maintenant, on peut donc créer des ServicesAccount (pour nos applications), et les relier à des Roles (limité à un namespace) ou des ClusterRoles (pour tout le cluster), eux mêmes respectivement reliés par des RolesBindings et des ClusterRoleBindings. Vous me suivez ?
Créer l’utilisateur (sur un master)
Le plus propre serait évidement de disposer d’une source d’authentification externe (type LDAP/AD ou autre) mais pour les besoins du tuto on va rester basique et fonctionner avec ce dont on dispose dans le K8s seulement, c’est à dire les ServiceAccounts. A noter, n’utilisez pas cela en production, ce n’est pas conseillé. Mettez en place une source externe type LDAP/AD/….
Sur un des masters où l’on a installé Kubernetes, on va donc créer un ServiceAccount avec kubectl. On l’utilisera par la suite pour se connecter en kubectl depuis notre poste client :
Par défaut, ce ServiceAccount n’aura accès à pratiquement rien. On va donc créer un ClusterRoleBinding qui va lier notre ServiceAccount avec un ClusterRole existant avec le niveau de privilèges qu’on souhaitera.
Pour obtenir la liste des ClusterRoles disponibles sur votre cluster, vous pouvez les lister avec la commande suivante :
kubectl get clusterrole
NAME AGE
admin 1d
cluster-admin 1d
[...]
view 1d
On privilégiera un ClusterRole avec juste les permissions nécessaires et pas plus, par exemple « view » pour commencer.
Note : Si le ClusterRole de vos rêves n’existe pas, vous pouvez toujours en créer un vous même avec les privilèges que vous souhaitez.
Récupérer les informations du cluster (sur un master)
Maintenant qu’on a créé le ServiceAccount et qu’il dispose d’un ClusterRole grâce au ClusterRoleBinding, un token a été créé par défaut et enregistré dans un Secret.
On le retrouve, puis on l’exporte
kubectl get secrets
NAME TYPE DATA AGE
[...]
myserviceaccount-token-bmwwd kubernetes.io/service-account-token 3 5m
Pour me simplifier la vie, je sette la variable K8SAPI pour éviter de retaper à chaque fois l’URL de l’API server qu’on a récupéré juste avant, mais rien ne vous y oblige ! On configure le « cluster » dans notre kubeconfig
Vous devriez maintenant avoir accès à votre cluster depuis votre poste client !
kubectl get nodes
BONUS : fichier .kube/config
Pour information, tout ceci est stocké dans un fichier config, créé par défaut dans dossier .kube de votre home directory (~/.kube/config). Si jamais vous êtes aventuriers, vous pouvez d’ailleurs tout écrire vous même, à la main ;-). Plus sérieusement, il peut être utile de savoir où il est pour pouvoir effectuer des modifications de masse, plus pratique qu’avec la ligne de commande kubectl config.
Ce fichier est le fichier par défaut, mais rien ne vous empêche d’en avoir plusieurs si vous ne voulez pas gérer vos contextes dans un seul et même fichier. Si vous décider d’en avoir plusieurs, il faudra indiquer à kubectl QUEL fichier vous voulez utiliser.
Soit en modifiant la variable d’environnement :
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
Soit en spécifiant explicitement le fichier config à utiliser à chaque commande :
kubectl --kubeconfig <PATHTOKUBECONFIG> .....
BONUS : Erreur certificate signed by unknown authority
En cas d’erreur « Unable to connect to the server: x509: certificate signed by unknown authority », vous avez 2 possibilités :
Le plus « quick and dirty », c’est de tout simplement ignorer le certificat du cluster. On peut, à chaque appel de kubectl dire qu’on souhaite ignorer le certificat avec le flag « –insecure-skip-tls-verify », mais tant qu’à faire bourrin, autant le setter directement au niveau du cluster :
La BD (dont j’ignore qui est l’auteur car je n’arrive pas à déchiffrer sa signature et je n’ai pas trouvé de crédits sur le site de SAP ou dans le tweet), nous relate les aventures d’un chef de projet qui, après de nombreux déboires avec l’open source, décide de prendre SAP, car c’est beaucoup plus simple.
Délicieux.
Vous avez dit bashing ?
Vous savez ! Le bashing. Cette expression anglosaxonne, qu’on nous sert à toute les sauces depuis quelques années dans les medias et sur les réseaux sociaux.
Le bashing (mot qui désigne en anglais le fait de frapper violemment, d’infliger une raclée) est un anglicisme utilisé pour décrire le « jeu » ou la forme de défoulement qui consiste à dénigrer collectivement une personne ou un sujet. –Définition Wikipedia (c’est quand même beau, le communautaire)
Alors c’est sûr que ce terme est carrément détourné de son utilisation initiale. Car aujourd’hui, on parle sans discernement de Mélenchon bashing, mais aussi de Benzema bashing, ou même de plastique bashing. On en est là
Vous n’êtes probablement pas sans le savoir, mais pendant très longtemps, l’open source et les logiciels libres ont étés pendant longtemps mal vus dans le monde professionnels.
Combien de fois on a entendu dire :
« C’est un projet libre développé par des barbus dans un garage » (NdA : ça marche aussi pour les défenseurs des libertés individuelles)
« C’est gratuit, ça marchera jamais »
« Pourquoi tu contribues à ce projet ? Tu devrais te faire payer pour ça ».
Si ça ce n’est pas de l’open source bashing… je ne sais pas ce que c’est !
C’est lui qu’a commencé !
Le summum de l’open source bashing est très probablement décerné pour l’éternité à Microsoft et à Steve Ballmer pour son célèbre « Linux is a cancer » de 2001.
Cependant, pas de chance pour Ballmer, il a fallut se rendre à l’évidence. La plupart des entreprises, d’abord les plus grandes, puis de plus en plus petites, utilisent massivement des solutions Linux et/ou qui ne fonctionnent que sous Linux. Tant qu’on était dans le monde des serveurs physique, on premise, ça allait encore.
Tourne. Tourne ! Touuuuuuuuuurne !
Mais l’avènement de la virtualisation a forcé Microsoft a changer son fusil d’épaule.
Les premières versions d’Hyper-V, très très peu performantes lorsqu’ils s’agissait de faire tourner des VMs Linux, faisaient perdre un business considérable à Microsoft. Ceci a profité à VMware, déjà leader (et dans une moindre mesure à Citrix et KVM), qui a creusé le gap.
Cela avait, si ma mémoire et bonne, forcé Microsoft a passer un partenariat d’abord avec SUSE Linux, puis avec les autres grandes distributions et m’avait beaucoup surpris à l’époque.
Aujourd’hui, pour se décoller de cette image de l’arch enemy de l’open source, Microsoft dépense des sommes considérables en contribution sur tous les projets open sources qu’ils peuvent trouver. Microsoft a même mis en place un site dédié, open.microsoft.com, pour mettre en avant leurs contributions :
We are all in on open source
–Satya Nadella (CEO actuel de Microsoft)
Ça ne les a pas empêcher de se prendre un bon gros badbuzz lors du rachat de Github.com pour presque 8 milliards de dollars.
« Pourquoi le rachat de GitHub par Microsoft pour 7,5 milliards de dollars choque Internet » titraient alors les journaux. De nombreux projets ont quittés les navires Github.com en protestation, sans se rendre compte qu’ils avaient toujours été sur une plateforme fermée (Carl Chenet en parle assez bien dans son article Le danger Github).
Au delà de Microsoft
D’autres on suivit la tendance. On peut à la fois open sourcer une partie de son code et/ou contribuer à de nombreux projets tout en faisant du business sur du closed source. Ce n’est pas forcément éthique, mais c’est communément accepté.
Un exemple parmi tant d’autre : VMware, qui a racheté Pivotal et qui met en avant de nombreux produits open source, tout en continuant à capitaliser sur les juteuses recettes de ses logiciels privateurs.
Et malgré ça, de grosses sociétés vendant des logiciels archicomplexes et fermés continuent leur lobbying. Quelques exemples me viennent en tête :
Un gros ETL qui explique que vous allez vous planter si vous prenez la solution Open source. L’image choisie pour illustrer le texte est un âne montrant les dents (je ne l’ai pas retrouvée).
Un logiciel d’entreprise d’échange de fichiers qui va vous coûter vos 2 bras vous explique qu’en fait vous allez perdre de l’argent si vous utilisez les technos libres. L’exemple qu’ils prennent pour illustrer leur propos est « FTP ». Forcément, comparer un système de communication qui coûte des centaines de K€ / an et FTP, j’espère bien que leur logiciel est mieux !
Et donc … SAP
On décortique le tweet de SAP ?
Dans le cas du jour, on est vraiment dans ce type de caricature.
Dans le comic, le projet n’avance pas pour plein de raisons ! C’est la catastrophe !
« Il faut ENCORE installer la nouvelle release. La 2.65 béta en plus ! »
Sous-entendu, les logiciels libres changent régulièrement de version, et ne sont pas stables au point qu’on soit obligé d’utiliser des béta pour se sortir des bugs bloquants.
C’est d’une mauvaise foi sans nom. Nombre de projets libres sont correctement outillés pour gérer proprement les releases, avec des contrôles qualité et des règles de développement très strictes.
Et inversement, nombre de logiciels, open source ou pas, déploient en production du code mal testé, parfois avec des impacts catastrophiques sur les utilisateurs (très récemment la Fall update de Windows 10 qui n’a pas passé toutes les étapes de validation mais est quand même partie en production).
« version pas compatible avec mon module / le texte qui passe en jaune »
Effectivement, monter de toute pièce une architecture basée sur de nombreuses briques (qu’elles soient libres ou pas en fait, mais bon on est plus à ça près), induit son lot de déconvenues et de problèmes de compatibilité à gérer.
Mais considérons l’alternative. Sur un gros logiciel bien mastoc (genre, un ERP, au hasard), comment ça se passe en général ?
Généralement (vécu à de nombreuses reprises), il y 2 cas :
Soit l’entreprise à les reins suffisamment solides pour mettre en place un processus complexe et dédie une équipe entière au maintien de l’ERP à jour (donc très coûteux).
Soit ce point est complètement occulté. Dans ce dernier cas de figure, les admins se retrouvent le bec dans l’eau au premier bug, avec un support qui refuse de résoudre tant que la solution n’est pas « à jour ». Au final, on se retrouve avec un ERP jamais mis à jour, de peur de tout casser, avec des failles de sécurités de partout.
C’est sûr, c’est beaucoup mieux.
« Et le fork, on en fait quoi ? »
Bonne question !
Sous-entendu, a un moment donné, le code a du être forké (pour effectuer des modifications ou appliquer des fix maison) mais l’application officielle a fini par diverger.
Effectivement, si les entreprises souhaitent utiliser l’open source mais ne pas faire profiter le projet de leurs contributions, on va dans le mur ! Mais est ce que ce n’est pas l’entreprise et ses mauvaises pratiques qui est seule responsable, dans ce cas là ?
Donc pour ce point précis, j’ai une solution toute trouvée => si vous utilisez du logiciel open source, contribuez. Ne me remerciez pas, c’était cadeau.
« Faut acheter un autre serveur / Rachète un serveur / Essaie avec un serveur d’une autre marque »
Alors là … je ne sais pas quoi dire. Cet argument, martelé 3 fois (donc ça doit être un point important), est incompréhensible.
Et pourtant, SAP contribue au libre !
Mais le plus incompréhensible dans cette histoire, c’est que SAP fait partie de ces entreprises qui s’engagent dans l’Open Source ! SAP a open sourcé 4 gros projets (et plusieurs centaine plus petits en tout), disponibles sur Github !
Je suis pratiquement certains que tous les produits de SAP reposent en partie sur nombre de composants open source tiers. Au delà de cette simple intuition (tout le monde utilise de l’open source, que ce soit des libs ou des intégrations vers des produits tiers), 2 indices tendent à prouver que j’ai raison, a minima pour une partie des outils vendus par SAP.
La première, c’est la liste OFFICIELLE des contributions sur des projets externes auxquels SAP (l’entreprise) contribue de manière régulière. SAP n’a aucun intérêt à contribuer activement à ces logiciels, sauf s’ils sont utilisés dans leurs propres logiciels.
Je ne sais pas de quel logiciel il s’agit ou si cela s’applique à TOUS les logiciels vendus par SAP, mais ça prouve que c’est le cas pour au moins un.
Au final
Au final, les défenseurs de ce tweet vont me dire que je suis simplement mauvaise langue car c’est simplement de la communication maladroite plutôt qu’une réelle volonté de dénigrer l’open source.
Et en même temps (je n’arrive pas à m’empêcher de le dire, pas merci Manu), quand on fait de la comm’, on ne peut pas ignorer que l’open source Bashing, historique, est fortement ancré dans les entreprises et particulièrement chez les gens « qui ont toujours fait comme ça« .
L’argument que l’open source est considéré comme non fiable continue probablement d’avoir un écho dans les oreilles du top management. Et ce sont eux, la cible de ce genre de pubs. Pas l’ingénieur système ou le dev qui fait un peu d’open source le soir, ni même le chef de projet.
Donc non, je ne pense pas que ça soit maladroit; au contraire, je pense que c’est voulu et c’est même très habile.
Yeah, I have said that I wouldn’t write opinion pieces, but then, who can blame me when I find this in my Twitter from SAP France account (sponsored, of course).
This comic series (I couldn’t find the author name anywhere) tells the story of a project manager that has to implement a big computer science project. In this particular episode, he thought it was a good idea to try to do it with open source solutions.
But clearly his team fails to deliver, having all sort of « open source » related issues. In the end, it’s SO MUCH EASIER to choose SAP.
Riiiight. As if we don’t know anybody among our profesionnal relations that struggled with SAP ;-).
Did you say bashing ?
I don’t know for sure if the word bashing still only has it’s colorful first signification in english (like bashing someone’s head in), but in french, we heavily borrowed your word to describe the act of systematic denigration of a person or a subject.
A quick search of « bashing » terms in my favorite search engine gave me: (French politician) Mélenchon bashing, but also (French footballer) Benzema bashing, and even plactic bashing. This has gone too far… :p
If you are an IT professional, you might already know that for a long time, free open source softwares were frowned upon in the professional world.
More than once, I heard :
« It’s free, it’ll never work… »
« Why do you contribute to this free project? You should get paid for this work rather than give it away freely ».
« It’s a free open source software developped by bearded men in a garage » (being bearded clearly is an issue here. Which is funny if you consider that hipsters fashistas now all wear beards. And that Microsoft started in a garage…)
If that’s not open source bashing, I don’t know what is…
He’s the one who started it!
Maybe he’s not the one, but the ultimate quote of open source bashing is probably given for eternity to Steve Ballmer from Microsoft for his world famous « Linux is a cancer » in 2001.
Tough luck for Ballmer, that was a big mistake. Most companies, starting from the biggest but now more and more average to small businesses rely heavily on open source solutions and solutions that work only on Linux/Unix systems.
While it was not so much of a problem when we lived in the physical servers world, on premise, it was still OK.
Turn. Turn! Turn aroouuuuuuuuund!
Virtualization was the first nail in the coffin.
First version of Hyper-V, Microsoft attempt (ahah) at a professional virtualization platform was excruciatingly slow/broken/not suited for Linux/Unix runtimes. This benefited mostly to VMware (and in some proportion to Citrix and KVM), which was already the leader back then and also resulted in a considerable loss of market share for Microsoft in this area.
If I remember correctly, that’s around the time when Microsoft began to make less vindicative statement about Linux. It even resulted in a partnership with SUSE Linux first, then other distribs, and I remember because it surprised me a lot at that time.
Nowadays, Microsoft can’t shake off the idea that’s it’s some kind of open source arch enemy, no matter how much is spent on contributions on open sources projects. Microsoft communicates heavily on the fact that they are (as a company) one of the biggest (if not the biggest) contributor in open source, far before Google or Redhat (I don’t know if IBM acquisition changes anything to this). They even have a website claiming their love for open source open.microsoft.com!
We are all in on open source
–Satya Nadella (actual CEO of Microsoft)
Nothing seems to matter. When they bought Github.com for nearly 8 billion dollars, the Internet nearly took the pitchforks out. « Why Github acquisition by Microsoft chocks the Internet » were titling newspapers. In the process, a lot of open source teams left Github in a hurry, never realizing that they had been on a closed platform all along and that Microsoft decision changed virtually nothing. There is a great article about this called Le danger Github but sadly (for you) it’s only in french…
And the others?
Many followed the trend. It’s commonly admitted (even though some might call it a little bit unethical) to play on both sides of the source (open/closed).
One example among many others is VMware, which acquired a few years ago Pivotal, contributes to open source projects, and open sourced some of it’s own. While at the same time maintaining a large part of it’s portfolio closed source and making a lot of money with it.
Still, with all these possibilities, some big companies, selling uber-complex softwares still continue to choose open source bashing to promote their product. Among the years, I came across these examples:
A big company selling an ERP/ETL, claiming that should you use the open source alternative, you will fail. The image chosen for the illustration was a Donkey showing teeth, looking really dump and silly (sadly, I didn’t think to take a screenshot at that time)…
A company selling a platform to secure file transfers (one of the most costly software I ever came across), explaining us that you will in fact loose money if you choose an open source solution rather than their own. They made the comparaison between their software and … plain FTP. Well, for a paid solution, I do hope that their solution is better! But choosing to ignore the open source solutions that DO compete with their product is not really fair (to say the least).
An then, there is SAP
Should we take a look again at the tweet?
Today’s comic is caracteristic of those caricatures of a comparison we get from those companies.
So? How is progressing your data platform based on open source software
From the look of our hero, I guess it not going well…
« We need to install the new release AGAIN! » / « 2.65 beta! »
The main idea to convey here is that open source software are unreliable. The versions change quickly to compensate blocking bugs. They are even so buggy that you need to deploy betas in order to hope to make it run.
Now that’s really bad-faith. There are many open source project ran by teams adamant on stability, delivery process and proper quality checks and tools.
On the contrary, many software project do deploy badly tested code, open source or not, with sometimes catastrophic impacts. One example very close to us is the last October update of Windows 10, which has skipped one of the usual validation steps to be released in production early (maybe just to be on time) which deleted some users directories!
« Wait! It’s not compatible with my module! » / « Why is the text highlighted in yellow in the new version? » »
One part in this is true. Building a complex solution from multiple components is indeed a challenge (open source or not… but let’s not stray) and does indeed brings a certain number of problems. You can’t improvise this and have to build procedures to avoid major issues.
But let’s consider for a second the alternative we are proposed here. Let’s take a total random example, say, a big bad closed source costly ERP. How does it’s lifecycle plays out?
I’ve seen it countless times, there are 2 types of companies :
Heavily staffed and organized. They take this big software and they do it right. Meaning: they put up a whole team whose sole purpose is to maintain the whole platform up-to-date. They don’t do anything else, it’s really costly.
Small or(/and) not organized. The maintaning up-to-date is « just a thing », in the mind of the board. Why put so much resources, when actual admins can do it when they have time? And that’s were the fun begins. In those companies, at the first bug, the support of the big software will tell the admin to update, before even taking a look at the case. You end up with an ERP that is kept in a working state but never updated, in case something could break. Hackers/security auditors will be so happy ;).
« And the fork, what do we do with it? »
That’s an excellement question, and I’m really glad you asked.
The idea here is that, at some point, the team in charge had to fork an open source project, maybe to patch with an homemade fix or to add a missing functionality. Eventually, the real open source project moved on and now, our team doesn’t know what to do. Forget their work and switch back to the main project, or continue to maintain their own copy while the main project grows?
Let’s be honest here. If you rely on open source softwares and don’t contribute your improvments (be they fixes or functionalities), don’t expect your work to be future proof!
« Buy a new server / Buy another server / Try with a server from another brand »
I’d really like to have an opinion on this, because it’s seems important, as this is told 3 times. But unfortunatly I have no freaking idea of what critic of the open source the author meant.
Funnies of all, SAP does contribute to Open Source!
I have had trouble to understand this at all at first. Because I checked, SAP is one of those companies that DO contribute! In the past years, SAP open sourced 4 internal big projects (and a few hundred of little more), all available freely on Github!
I’m 98% sure (as you can see that’s a really precise metric :p) that all SAP softwares at least use a third party open source component. More than an intuition, it’s more the fact that everyone uses open source at some level, be it frameworks, libs, or third party modules to ease integrations with third party softwares.
Last, but not least, there is a documentation page on SAP website, listing FOSS and licences that go with them. That doesn’t say that all SAP software use open source, but at least one does.
In conclusion
Some might say that I’m over-reacting, that it’s just a bad tweet from France marketing team rather than a real will to undermine open source philosophy.
Yet, I can’t shake the idea that all the people in marketing from these companies MUST know that open source was for a long time a rude word. This probably still echos on the mind of people less close to today’s work, who have « always done it like this » and « don’t see a reason to change now ». Claiming that open source is unreliable will be probably most effective to top management.
And don’t be fooled, this tweet’s target is not developers or system administrators. This tweets aims top management, who have to decide weither they go for open source or SAP solutions.
No, I don’t think that’s a mistake; on the contrary, I think it’s done on purpose and probably very effective.
La conférence devrait être diffusée en temps réel sur Youtube pour ceux qui n’ont pas leurs billets, ou ceux qui me suivent depuis l’Australie ;). Le lien des confs est disponible ici :
Aujourd’hui, plutôt que de vous donner un playbook tout fait pour installer sans effort une des multiples applications dont j’ai automatisé le déploiement avec Ansible, je vous propose d’explorer une des features les plus importantes et utiles d’Ansible, les facts, par le biais d’un petit exemple.
C’est quoi les facts dans Ansible
Si vous avez déjà lancé un playbook, vous avez sûrement remarqué lors de son exécution, que la première tâche qui est réalisée n’est pas une tâche que vous avez demandée explicitement.
Cette tâche [Gathering Facts], qui ne fait à première vue rien, correspond en fait à la connexion à la ou les machines sur lesquelles seront exécutées les playbooks. Si la connexion échoue, le playbook échouera sur cette cible, et continuera éventuellement sur les autres (s’il en reste). Si l’hôte répond, alors Ansible en profite pour récupérer moult informations en rapport avec cette machines et les stockent dans une variable ansible_facts.
A quoi ça ressemble ?
Comme je ne disais, à première vue, cette commande de fait rien. Si on ne sait pas qu’elle stocke des informations dans une variables, on ne peut rien en faire.
Un bon moyen d’avoir un premier aperçu de ce qu’on peut en faire est de les afficher. On peut faire ça avec le module « setup », qui est en réalité le même module qui est appelé lors de l’étape [Gathering facts].
Le retour se fera au format JSON, ce qui est certes peu digeste, mais facilitera grandement les manipulations de type « filtre » (via le flag filter intégré ou via l’utilitaire jq par exemple).
Je ne vous copie-colle pas tout, rien que pour cette machine, j’ai 719 lignes… La quantité d’informations disponible est impressionnante, et on peut même en venir à se demander à quoi ça va bien pouvoir nous servir.
Ok, on en fait quoi ?
Du coup je profite de cet article pour faire un tuto tout simple et qui peut être utile dans de nombreux cas, réaliser des opérations différentes en fonction de la distribution de la machine concernée.
L’information qui va nous intéresser ici concerne donc les remontées en tant que « nom » ou « version » d’une distribution. Je vais vous économiser la lecture de nos 700+ lignes, et vous indiquer que vous pouvez trouver ces informations en filtrant sur les mots clés « ansible_distribution… » et « ansible_os… »
Voilà ce qu’on pourrait obtenir sur une machine CentOS :
Pour continuer dans l’exemple, on va faire une chose qu’il ne faut jamais faire : désactiver le firewall et SELinux.
Imaginons que vous souhaitiez quand même le faire. Si vous lancez ce playbook sur tout votre parc et qu’il n’est pas homogène, vous allez tomber sur des groupes de machines Ubuntu, CentOS 5, 6, 7…
Un moyen de gérer les cas particuliers pourrait être de les classer tous vos hosts dans des groupes, et de créer un playbook pour chaque OS/version, restreint à un groupe de machines uniquement.
---
- hosts: rhelcentos6only
tasks:
[…]
Ce n’est d’ailleurs pas une mauvaise idée, surtout pour gérer les distrib aussi différentes que RHEL et Ubuntu par exemple.
En revanche, dans le cas de RHEL, on a des différences qui apparaissent à partir de la RHEL 7, notamment la gestion du Firewall qui passe de IPtables à firewalld.
On va donc faire appel à la clause when: de ansible, qui conditionne l’exécution d’une tâche (ou d’un rôle ou d’un block) à une validation. Et ça donnerait quelque chose comme ça :
---
- hosts: rhelcentos6only
tasks:
- name: "shutdown and disable IPtables for RHEL <= 6"
service:
name=iptables
state=stopped
enabled=no
when: (ansible_distribution == "CentOS" or ansible_distribution == "RedHat") and
(ansible_distribution_major_version <= "6")
- name: "shutdown and disable firewalld for RHEL >= 7"
service:
name=firewalld
state=stopped
enabled=no
when: (ansible_distribution == "CentOS" or ansible_distribution == "RedHat") and
(ansible_distribution_major_version >= "7")
- name: "disable selinux"
selinux:
state=disabled
Dans cet exemple, lors de l’exécution du playbook, on aura donc, pour chaque VM CentOS ou RHEL, une tâche qui sera exécutée, et l’autre qui sera marquée « skipping » (en bleu clair) et le playbook marchera pour toutes les RHEL, quelque soit leur version.
Aller plus loin
Il existe une page spécifique sur la documentation d’Ansible pour parler des conditions dans les playbooks, accessible à l’adresse suivante : https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html
Vous pouvez aussi utiliser les facts dans les options des tasks, et dans les templates, en encadrant le nom de la variable souhaitée avec des « doubles curly braces » : « {{}} »
Le moins qu’on puisse dire, c’est que l’utilisation des API pour une opération aussi régulière qu’une sauvegarde (ou la suppression des vieux index, par exemple) est quelque chose d’assez lourd à mettre en place.
Un des lecteurs avait pris le temps de me conseiller un outil fourni par les gens de chez Elastic, et qui permet de gérer plus simplement ces tâches fastidieuses : Curator.
Prérequis côté serveur
J’avais donc dis que je regarderai et j’ai donc profité d’un de mes clusters ElasticSearch sur Kubernetes pour tester l’outil.
La première chose à faire est donc de récupérer l’adresse IP (ou le nom DNS) qui nous permet d’accéder à l’API web de notre cluster ElasticSearch. Pour rester cohérent avec l’exemple, je vais dérouler la procédure de mise en place d’une sauvegarde avec Curator dans un cluster Kubernetes qui contient un cluster ElasticSearch existant (ça ne complique pas beaucoup). Mais dans tout les cas il vous faudra une adresse ;-).
kubectl --context=andromeda --namespace=elastic get svc elasticsearch
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
elasticsearch ClusterIP 10.10.10.15 9200/TCP,9300/TCP 115d
En se connectant dans le container Elastic, je peux regarder comment est configuré la base, et en particulier les destinations physiques « repo ».
Dans le cas d’ElasticSearch en tant que container Docker, il existe dans l’image Docker officielle une variable REPO_LOCATIONS. Dans mon cas, j’ai donc modifié la configuration de mon déploiement pour spécifier à ElasticSearch où trouver les variables.
Pour ceux qui n’utilisent pas Elasticsearch en tant que cluster Docker (si vous l’avez installé avec un de mes playbooks Ansible par exemple), vous pouvez éditer le fichier de configuration et ajouter les lignes suivantes (et vous assurer que le chemin existe effectivement) :
sudo vim /etc/elasticsearch/elasticsearch.yml
[...]
path:
repo: ["/my/backup/directory/path"]
[...]
Redémarrer ElasticSearch pour prise en compte (ou deletez le pod, niark niark niark). Notre base ElasticSearch sait maintenant où déposer les futures sauvegardes.
Prérequis côté client
Lancer un curl sur l’adresse IP que vous avez collecter au début du tuto, pour voir si on arrive à lister les indices présents.
Dans mon cas, je lance un container Ubuntu directement dans le cluster K8s pour faire simple.
kubectl --context=andromeda run my-shell --rm -i --tty --image ubuntu -- bash
#install prerequisites for curl
apt-get update
apt-get -y install curl
#do the actual curl
curl -X GET "10.10.10.15:9200/_cat/indices?v"
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open awesomeapp-health-2018.11.30 6VrEZk-XTGm3eeKJEzDZnA 5 1 17054 0 2mb 2mb
[...]
OK ! On a bien accès à l’API. On peut maintenant configurer la variable d’environnement REPO_LOCATIONS
Cette partie du tuto était identique (à Kubernetes près) au tutoriel précédent. Maintenant, ça diffère.
On va installer Curator, mais pas via le gestionnaire de package du système. En effet, si vous avez une version récente d’ElasticSearch et que vous vous contentez d’APT, vous risquez d’obtenir l’erreur suivante :
apt-get install elasticsearch-curator
curator_cli show_indices
elasticsearch.exceptions.ElasticsearchException: Unable to create client connection to Elasticsearch. Error: Elasticsearch version 6.3.0 incompatible with this version of Curator (5.2.0)
La version conseillée par Elastic est l’utilisation du gestionnaire de package Python (pip) :
Dans ce tutoriel, on va commencer par utiliser la CLI de Curator. Mais il faut savoir qu’il existe aussi une version qui permet de jouer des scenarii prédéfinis (les Actions). Du coup, il est logique que tout la partie connexion et authentification soit gérée par un fichier de configuration. Malheureusement, cette partie n’est pas super bien documentée si on se contente de la doc d’install (il faut fouiller un peu). Dans les grandes lignes, voilà ce qu’il faut faire :
Maintenant qu’on a Curator qui peut se connecter à ElasticSearch, on va enfin pouvoir lancer notre sauvegarde, via la feature des snapshots ! (Plus d’info sur les filtres, vous pouvez aller sur la page de documentation officielle)
La commande devrait prendre un certain temps, en particulier si vous avez beaucoup de données. Une fois qu’elle a rendu la main, vérifiez que le snapshot existe, avec la CLI, et en allant voir le contenu du dossier configuré précédemment.
root/.local/bin/curator_cli show_snapshots --repository svg
curator-20181204095300
ll /data/bck
total 36
drwxr-xr-x 3 elasticsearch elasticsearch 4096 Dec 4 09:54 ./
drwxr-xr-x 6 elasticsearch elasticsearch 4096 Dec 4 09:47 ../
-rw-r--r-- 1 elasticsearch elasticsearch 29 Dec 4 09:54 incompatible-snapshots
-rw-r--r-- 1 elasticsearch elasticsearch 5522 Dec 4 09:54 index-0
-rw-r--r-- 1 elasticsearch elasticsearch 8 Dec 4 09:54 index.latest
drwxr-xr-x 56 elasticsearch elasticsearch 4096 Dec 4 09:53 indices/
-rw-r--r-- 1 elasticsearch elasticsearch 103 Dec 4 09:53 meta-yMBl9IsPRYGCitWqGjxh2Q.dat
-rw-r--r-- 1 elasticsearch elasticsearch 470 Dec 4 09:54 snap-yMBl9IsPRYGCitWqGjxh2Q.dat
Je suis expert en sauvegarde moi, pas en restauration…
True story
Bon, sauvegarder c’est bien, restaurer c’est mieux ! Il existe bien évidemment une commande restore pour ça
Clairement, on ne va pas se contenter de ça. C’est déjà mieux que précédemment avec les appels d’API, mais on peut faire encore mieux. Déjà, si vous avez fait attention, j’ai teasé qu’on pouvait gérer les indices (et ainsi virer les plus vieux) avec Curator. C’est clairement un usecase hyper sympa de l’outil.
Ensuite, j’ai également teasé la possibilité de gérer des tâches en mode batch, avec les actions, qui sont des fichiers de définition simple de vos actions à faire avec Curator. Il y aura bien entendu des articles à suivre pour en apprendre plus
Après EKS (Amazon) et GKE (Google) (et plein d’autres en fait), Azure a fini par lancer aussi son service managé de Kubernetes (preview en octobre 2017).
Ce service ne doit pas être confondu avec ACI (Azure Container Instances) qui est le service d’Azure CaaS, où vous pouvez instancier les containers à la demande sur les Kubernetes d’Azure, où Kubernetes vous est complètement caché.
Vous verrez aussi peut être dans la littérature des références à ACS (l’ancien nom d’AKS) ou alors de ACS-engine, qui est le projet utilisé par Azure pour déployer des clusters Kubernetes (sur du IaaS) pour leur besoins propres et qu’ils ont open sourcé.
Il s’agit donc bien d’un service fourni par Azure, qui masque toute la complexité du déploiement des machines et des composants de Kubernetes. Vous n’aurez pas accès aux VMs, on n’est donc pas sur du IaaS. Mais contrairement à ACI, vous aurez les pleins pouvoir sur le control plane de Kubernetes, et vous pourrez l’administrer comme bon vous semble.
C’est vraiment facile à installer ?
Oui, c’est vraiment simple. L’installation peut se faire depuis le portail ou en quelques commandes « az cli »
Pour tout vous dire, Microsoft a même pousser le vice jusqu’à faciliter l’installation du binaire kubectl, ainsi que la configuration de votre cluster dans les contextes (via des commandes « az cli »). Dans l’absolu, les commandes qu’on va faire ci dessous sont équivalentes à celles que j’ai décrites dans l’article Installer kubectl et Configurer kubectl.
Nice to have
C’est parti !!
Depuis le portail, cherchez « Kubernetes services », puis cliquez sur « Add ».
Et si vous préférez comme moi le faire en lignes de commande, ça donne quelque chose comme ça :
az group create --name myownkubernetescluster --location westeurope --subscription "mysubscription"
az aks create --resource-group myownkubernetescluster --name myawesomeclsuter --node-count 3 --enable-addons monitoring --node-vm-size Standard_B2s --kubernetes-version 1.10.9 --ssh-key-value ~/.ssh/mypublicsshkey.pub --subscription "mysubscription"
Si vous l’avez fait depuis le portail, vous verrez également une popup sur la droite pour vous aider à configurer kubectl (mais vous pouvez aussi les utiliser si vous avez monté le cluster avec les commandes précédentes aussi).
Les commandes à lancer après avoir déployé le cluster sont les suivantes :
az aks install-cli
Downloading client to /usr/local/bin/kubectl from https://storage.googleapis.com/kubernetes-release/release/v1.12.0/bin/linux/amd64/kubectl
Please ensure that /usr/local/bin is in your search PATH, so the `kubectl` command can be found.
Si vous essayez de les lancer sans avoir fait votre az login, vous aurez l’erreur suivante
az aks get-credentials --resource-group myownkubernetescluster --name myawesomeclsuter
Resource group 'test_AKS' could not be found.
On se logue, donc
az login
Note, we have launched a browser for you to login. For old experience with device code, use "az login --use-device-code"
Comme l’indique la commande, az cli à récemment changé de méthode d’authentification par défaut.
Si vous lancez ces commandes et que vous n’avez pas d’environnement graphique (dans une petite VM par exemple), vous pouvez toujours utiliser l’ancienne méthode avec un code à recopier dans une page web avec la commande suivante :
az login --use-device-code
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code TOTOTOTOTO to authenticate.
Dans mon cas, j’ai accès à un abonnement Visual Studio en plus de mes souscriptions habituelles.
Par défaut, cette souscription est filtrée, donc az cli continuera à ne pas « voir » le ressource group que j’aurai créé pour l’occasion. L’idéal est de l’indiquer explicitement en ajoutant un « –subscription ». Une autre solution, plus simple, pour éviter le problème est de positionner cette souscription comme « par défaut »
az account set --subscription "Visual Studio"
Maintenant ça devrait marcher. On récupère les crédentials et les informations du contexte.
Par défaut, az cli va merger ces informations avec votre .kube/config existant s’il existe. Si vous avez peur qu’il fasse des bêtises, pensez à le sauvegarder avant.
az aks get-credentials --resource-group myownkubernetescluster --name myawesomeclsuter
/root/.kube/config has permissions "644".
It should be readable and writable only by its owner.
Merged "testaksdge" as current context in /root/.kube/config
Maintenant que l’outil az cli a configuré notre contexte pour nous, on peut interagir avec le cluster normalement :
kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-nodepool1-36034183-0 Ready agent 26m v1.10.9
aks-nodepool1-36034183-1 Ready agent 26m v1.10.9
aks-nodepool1-36034183-2 Ready agent 26m v1.10.9
Lancer le « proxy » (pour afficher le dashboard et accéder à l’API)
az aks browse --resource-group myownkubernetescluster --name myawesomeclsuter
[...]
Proxy running on http://127.0.0.1:8001/
Press CTRL+C to close the tunnel...
[...]
Etape supplémentaire si vous avez activé le RBAC
Si vous avez activé le RBAC, ce que je vous conseille fortement et qui devrait être le choix par défaut, votre dashboard n’aura pratiquement accès à rien !
Il faut lui ajouter des droits sur le cluster. La procédure complète d’Azure vous indique la marche à suivre ici. Ce que eux conseillent, qui est effectivement le plus simple (mais pas le plus sage), est de donner les droits cluster-admin au service account kubernetes-dashboard…
Mais attention aux conséquences ! De très nombreuses personnes laissent le dashboard ouvert sur Internet et si EN PLUS votre dashboard est admin du cluster, vous allez rapidement miner des cryptocurrencies et lancer des mails de SPAM à votre insu…
N’autorisez donc pas le portail depuis l’extérieur.
Et après ?
Dans le cycle de vie d’un cluster Kubernetes, deux tâches vont très vite vous intéresser. Sauvegarder vos objets (ce qu’on peut faire avec Ark de Heptio) et mettre à jour votre cluster (ce qu’on peut faire avec AKS).
Dans une vie antérieure (article dans mes tiroirs depuis fin 2015 a priori XD), j’ai eu à gérer, on premise, du stockage hautement disponible HPE VSA pour mes clusters VMware.
Si vous êtes ici, c’est sûrement parce que vous aussi, vous avez acheté des LeftHand (StoreVirtual P4000) et/ou des HPE VSA, et que vous voulez les superviser.
La plupart des tâches d’administration se font depuis la CMC (Centralized Management Console), mais clairement ce n’est pas hyper pratique. La section 7 du manuel StoreVirtual traite de la supervision en général (http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c04581885-1.pdf)
Heureusement, la documentation explicite clairement qu’il est possible d’activer SNMP pour externaliser tout ça.
A noter, je n’ai pas pu m’empêcher de glousser en lisant cette petit phrase dans un manuel d’administration un peu plus ancien, qui dit que vous ne pouvez pas changer, ni même supprimer (#Sécurité), les communautés par défaut :
Section 7 du manuel d’administration http://www.hp.com/ctg/Manual/c01865545.pdf
Nagios / Centreon / Shinken
Pour superviser mes machines dans mes DC « on-premise », j’utilisais Centreon. Tout naturellement je me suis tourné vers Nagios Exchange pour voir s’il n’y avait pas déjà des gens qui avaient fait le travail.
J’avais également trouvé des ressources sur le site d’HPE, mais comme ils passent leur temps à le refaire les 3 liens que j’avais sauvegardés sont maintenant HS. Voilà voilà.
En gros, ce que ça disait, c’est que les MIB sont contenues dans l’installeur, celui qui est utilisé pour instancier les VSA la première fois.
Fallait le savoir…
Configurer SNMP
Comme les deux plugins utilisent SNMP, on va… l’activer. #ThanksCaptainObvious.
Depuis la CMC, on peut donc configurer nos StoreVirtual pour qu’elles acceptent des connexions SNMP et configurer une communauté (voir le manuel d’admin, page 93). Clairement, ce n’est pas sorcier.
Dans le Management Group, on a un menu Event, dans lequel on peut configurer un serveur SMTP (pratique pour recevoir les mails qui m’informe que mon cluster est à plat et que mes données sont définitivement corrompues et que je peux aller pointer à Paul Emploi).
Et, SNMP.
Checker
Maintenant que vous avez activé SNMP (avec une communauté bien complexe, readonly et des restrictions IP à vos seuls serveurs de supervision, on est d’accord), on peut voir si ça marche.
Personnellement j’ai préféré check_lefthand, car la doc est plus fournie et les options plus nombreuses .
./check_lefthand.pl -H 10.10.10.16 -C hyperdifficultcommunity
Cowardly exiting, not instructed to check anything!
check_lefthand.pl -H -C [-t timeout] [-p port]
Additional Options:
--module-space
report the available space on each 'module' within a management group
--module-status
report on the various status elements for each 'module' within a management group
--volume-space
report the available space on each volume within a management group
--volume-status
report on the various status elements for each volume within a management group
--cluster-space
report the available space for each cluster within a management group
--cluster-status
report the status of each cluster within a management group
Les deux alertes que j’ai mises en place sont l’état du clusters, et le status de mes volumes (synchronisés ou pas entre les 2 salles).
centreon$ ./check_lefthand.pl -H 10.10.10.16 -C hyperdifficultcommunity --cluster-status
OK - mgmt group: MyAwesomeHPVSA 5/5 Cluster Managers Active.
centreon$ ./check_lefthand.pl -H 10.10.10.16 -C public --volume-status
OK - mgmt group: MyAwesomeHPVSA 4 Volumes with valid replication and Data Protection.
A noter, tout n’est pas parfait. Dans certains cas, j’ai remarqué que l’alerte ne se déclenchait pas quand des nœuds étaient DOWN, car le compteur « total » de nœuds décrémentait en même temps que les nœuds tombaient (ce qui est très bête…).
Mais c’est quand même un début
Bonus : Rage
Ouais, je sais…HPE VSA (maintenant HPe StoreVirtual VSA), quoi. L’alternative « géniale » de HPE à VSAN.
Ne me blâmez pas… A l’époque, on m’avait donné le choix entre 2 appliances physiques NetApps plus chères et même pas hautement disponibles (actif/passif) et donc les fameuses HPE VSA Storevirtual. Et puis sur le papier, ça paraissait robuste. C’est basé sur un produit éprouvé, les Lefthands (appliances physiques) et un OS Linux.
What could go wrong?
Maintenant que je ne m’en occupe plus, je peux dire que c’est grâce à ce superbe outil que j’aurai fais un week end non-stop quasiment sans dormir au téléphone avec des techs HPE et VMware de tout autour du monde (mais je me suis fait payer plus de 25 heures d’astreinte #youpi) parce que les nœuds tombaient les uns après les autres sans raison apparente.
Pour les curieux, c’était un problème de hotspare qui se mettait en veille et bloquaient les nodes, les uns après les autres, dès qu’une commande « refresh storage usage » était lancée par l’ESXi (automatique ou manuel).
C’est aussi mon record personnel du ticket support le plus longtemps, tout constructeur/éditeur confondu. Les chiffres sont impressionnants :
un mois pour trouver un workaround (désactiver les hotspares, #genious)
plus de 200 emails
5 mises à jours (dont 4 inutiles)
3 interventions le soir sur la prod
Et last but not least : 2 ans pour trouver le fix (alors que le problème était détecté puisqu’on savait qu’il suffisait de désactiver les hotspares).
DEUX… ANS…
Au final, je ne suis même pas vraiment sûr que le problème soit fixé.
Je ne suis plus sûr de rien, à part du niveau de compétence de HPE sur le sujet des serveurs et du stockage.
Mais qui peut les blâmer, ce n’est pas leur cœur de métier après tout. #ohwait
Ça y est !! Je travaille enfin dans une entreprise où les gens qui le souhaitent peuvent travailler sous Linux. Exit les VMs hyper-V ou Virtualbox, le Linux subsystem for Windows, Docker for Windows, minikube, et autre bidouilles pour faire mon travail.
Malheureusement, tout le monde n’est pas encore totalement convaincu, et je suis encore amené à travailler avec des gens qui n’ont pas (encore ?) sauté le pas.
Come to the Dark side… we’ve got cookies
Quand ces gens là m’envoient des clés SSH (c’est bien les publiques que je veux, hein Loïc ;p), ils utilisent PuTTYgen, comme presque tout le monde sous Windows (livré avec le célebrissime PuTTY).
Et vous ne le savez peut être pas, mais PuTTYgen ne sait générer que des ppk (le format de PuTTY) et éventuellement de les convertir au format SSH2. C’est donc dans ce dernier format qu’ils m’envoient leurs clés.
Et en quoi ça gène ?
Souvent, ces clés sont utilisées pour se connecter à des machines sous Linux, qui la plupart du temps disposent d’un serveur OpenSSH. Et par défaut, les clés dans .ssh/authorized_keys doivent être au format OpenSSH, pas SSH2…
Mais c’est quoi la différences ?
Voilà à quoi ressemble une clé SSH2
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "generated_blop"
AAAABCDEFGHIxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxZZZZZZZZ==
---- END SSH2 PUBLIC KEY ----
On voit au final que les deux formats sont assez similaires. En fait, si vous avez la fleme de chercher la ligne de commande, pour obtenir la clé au format OpenSSH quand vous avez une clé au format SSH2, il suffira de supprimer les lignes « —–…. » et « Comment: « , puis de retirer les sauts de ligne pour tout mettre sur une seule ligne par clé (avec éventuellement un commentaire en fin de ligne).
Dans mon cas, on m’a donné BEAUCOUP de clés SSH2 et je n’avais pas encore de toute me les taper à la main.
La solution barbare
Pourquoi faire propre quand on peut faire du sed, tr et des regex ?
sed -e "/^[---|Comment]/d" my_ssh2_key | tr -d '\n'
La VRAIE solution
Au final, même si la solution précédente me faire sourire, la vraie solution est simplement d’utiliser le binaire ssh-keygen qui dispose d’une fonction pour le faire « out of the box ».
ssh-keygen -i -f ssh2.pub
Pour un répertoire donné ou toutes les clés à convertir sont des fichiers textes dont le nom de fichier se termine par « key », lancer la commande suivante :
for i in `ls -1 *key`; do echo "$(ssh-keygen -i -f $i) $i"; done
Cerise sur le gateau, si vous en avez beaucoup, vous serez content d’avoir le nom du fichier initial en tant que commentaire OpenSSH à la fin de la clé (c’est ce que fait le $i à la fin de mon « echo ».
Et là si on veut le copier coller directement dans le .ssh/authorized_keys :
for i in `ls -1 *key`; do echo "$(ssh-keygen -i -f $i) $i >> ~/.ssh/authorized_keys"; done
Fun fact sur PuTTY qui n’a rien à voir avec la choucroute
En astreinte avec un N3 de chez VMware qui travaillait aux Etats Unis, j’ai passé une dizaine de secondes au téléphone à ne pas comprendre de quoi il me parlait et lui demander de répéter.
En fait, il me demandait d’ouvrir un terminal PuTTY et je n’avais jamais entendu comment était prononcé PuTTY à part en France. On dit généralement « pou-ti » ou parfois « pu-ti ».
Aux US (et probablement dans tous les pays anglosaxons), on le prononce « peuh-ti ».
La prochaine fois, vous pourrez vous la péter et prononcer PuTTY avec l’accent de l’oncle Sam ;-).
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 ».
D’ailleurs, attention, le nombre de place est limité à 80 et elles partent vite…
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 un tour des news de l’écosystème CNCF
#1 Dans ton Kube : retour sur 2 ans d’incidents en production
A 19h30, je parle => petit pitch pour vous vendre le truc
Pour héberger ses services cloud, Lectra a misé sur Kubernetes. Et si personne n’a réussi (pour l’instant) à planter TOUTE la Prod, ça a parfois secoué un peu ;-).
Je reviendrai donc sur ces deux années passées par la team Ops, et vous partagerai quelques petites tips, souvent apprises sur le tas.
#2 Pourquoi le Chaos Engineering ?
And last, but not least, à 20h15, Sylvain HELLEGOUARCH nous parlera de Chaos Engineering !
La richesse de nos systèmes s’accompagne de plus en plus d’une complexité accrue qui diminue la capacité des parties prenantes à anticiper les échecs potentiels ainsi que leurs impacts et conséquences. Une simple panne, qui sur le papier semble anodine, peut conduire à une catastrophe. Il est désormais nécessaire de mettre en places des pratiques visant à re-gagner de la connaissance sur nos systèmes : observabilité et chaos engineering sont les deux plus spécifiques sur ce sujet. Nous allons discuter dans cette session du Chaos Engineering et de son apport dans ce contexte.
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 nos hôtes
Comme dans la vie de tout projets, on installe un logiciel, et sur le moment ça nous suffit, on est contents.
Mais arrive le jour fatidique où le logiciel est obsolète et il faut mettre à jour la base. Sans aucun créneau de maintenance pour le faire bien entendu car elles sont évidemment utilisées en production ;-).
Prérequis
Bon point pour moi, je n’ai pas fais l’erreur d’avoir une base de données mongoDB « standalone ». Je dispose de cluster de bases de données MongoDB (replicaSet, dans la terminologie mongo), que je vais donc pouvoir mettre à jour à chaud. Ça sera juste un peu plus long ;-).
3.4 => 4.0 = pas possible
Bon quand même, fallait bien que je tombe dans le piège.
La version majeure 3.4 (la dernière en date est la .19) ne peut pas directement être mise à jour vers une 4.0. Comme c’est une majeure, il faut passer d’abord par la majeure suivante, la 3.6 (c’est classique comme limitation).
On passe en 3.6 alors
Pour me simplifier la vie, j’ai un mini playbook Ansible qui me permet d’ajouter les dépôts en fonction de la version que je veux.
Clairement, on peut faire plus propre. Ici, c’est du oneshot sur quelques machines Ubuntu, donc je n’ai pas automatisé plus que ça. Mais si vous avez plus de machines à faire que moi, je vous invite à le raffiner un peu, par exemple en ajoutant le repo et la clé en fonction de la version donnée en paramètre.
Maintenant qu’on a bien les dépôts pour la version 3.6, on peut mettre à jour nos serveurs. Idéalement si on avait de nombreux clusters à migrer, il faudrait le faire avec un playbook Ansible (ou autre) qui passe sur les serveurs, uns par uns, les mets à jour et les redémarre.
Cependant, pour simplifier l’explication, je vais laisser la procédure telle quelle et tout faire à la main.
Sur les SECONDARY, uns par uns, mettre à jour manuellement le serveur, puis le redémarrer :
Vérifier que tout fonctionne à nouveau après redémarrage
mongo
MongoDB shell version v3.6.10
connecting to: mongodb://127.0.0.1:27017/?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("17272d4e-ecd0-49c2-a672-8804227ab0e4") }
MongoDB server version: 3.6.10
rs:SECONDARY>
Puis, se connecter sur le PRIMARY, et lui passer la commande suivante (qui va avoir pour effet de le rétrograder proprement et temporairement en tant que SECONDARY) :
$> mongo
rs:PRIMARY> use admin
switched to db admin
rs:PRIMARY> db.auth('myadmin', 'myawesomepassword')
1
rs:PRIMARY> rs.stepDown(180)
[...]
2019-01-25T15:23:02.520+0000 I NETWORK [thread1] trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2019-01-25T15:23:02.548+0000 I NETWORK [thread1] reconnect 127.0.0.1:27017 (127.0.0.1) ok
rs:SECONDARY>
Et enfin, mettre à jour manuellement le serveur de la même manière que les autres :
Ici, je viens de faire la migration de 3.4 vers 3.6. En réalité, ce n’est pas complètement terminé. L’ensemble des binaires ont beau être en version 3.6, la base elle, reste en « compatibilité » 3.4.
Pour s’en assurer, une connexion sur n’importe quel serveur permet de le vérifier :
On va donc aller sur le nœud PRIMARY pour passer la base en compatibilité 3.6 (le seul prérequis est qu’une majorité de serveurs aient leurs binaires mis à jour en 3.6 et redémarrés) :
Différence notable entre la version 3.4 et la version 3.6, c’est la façon dont sont gérés les replicaSets. La version 3.6 introduit la version 1 du protocol des replicaSet, et empêche les précédents clusters déclarés de fonctionner.
Il est donc nécessaire de mettre à jour le protocole avant de mettre à jour en 4.0.
Ouvrir un shell mongo sur le PRIMARY, et modifier la configuration du replicaset (rs) :
Bon, je ne vais pas vous refaire l’affront de vous copier coller la procédure de mise à jour : maintenant qu’on a mis à jour la version du replicaSet, c’est la même.
Pour rappel :
Relancer le playbook pour ajouter le dépôt de la version 4.0 (décommenter la ligne 4.0)
Mise à jour des serveurs SECONDARY puis redémarrage du serveur
Step down du PRIMARY
Mise à jour du PRIMARY devenu SECONDARY après le stepdown, puis redémarrage du serveur
Mise à niveau de la compatibilité de la base en 4.0
Et voilà, votre cluster est « up-to-date », après 2 upgrades de versions majeures et sans aucune interruption de service. Alors, comme on dit chez moi :
Pour ceux qui sont présents (et ceux qui ne sont PAS présents aussi, en fait), je met à disposition les slides du talk, un peu en avance.
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.
Le pitch, le pitch !
Je vous remet le petit pitch pour vous vendre le truc
Pour héberger ses services cloud, Lectra a misé sur Kubernetes. Et si personne n’a réussi (pour l’instant) à planter TOUTE la Prod, ça a parfois secoué un peu ;-).
Je reviendrai donc sur ces deux années passées par la team Ops, et vous partagerai quelques petites tips, souvent apprises sur le tas.
L’an dernier, j’atteignais avec fierté les 10000 vues par mois. Aujourd’hui, on atteint les 20000, avec un record en octobre dernier avec 22400 vues.
Et ce, sans écrire plus souvent (un temps évoqué car j’ai toujours une 60aines de brouillons en attente qui ne se dépilent pas). C’est même plutôt le contraire (suite à un heureux événement, je vous rassure ;)).
Et c’est pas fini…
Soyons honnête, ce qui m’a permis d’obtenir cette visibilité supplémentaire, c’est sans aucun doute les communautés IT existantes. D’abord, le gros du traffic non-récurrent provient du Journal du Hacker et de ses contributeurs, qui relaient régulièrement mes articles et je les en remercie beaucoup :).
Ensuite, je commence à agréger un certain nombre de followers, que ce soit sur Twitter (& Mastodon, on en reparle après), LinkedIn ou via la mailing list qui grossie lentement mais sûrement.
D’autres confs sont peut être à venir, puisque je poste régulièrement sur des CFPs :-).
Bon OK, mais tout ça, c’est très bien, mais le but du blog n’est pas de faire du chiffre (même si c’est toujours agréable). Le but reste de produire du contenu qui vous sera utile.
Les articles à venir
J’espère ne pas vous avoir perdu, car c’est la partie la plus importante !!
Comme je l’ai dis plus haut, j’ai toujours une 60aine de brouillons en attente (moyenne constante depuis quelques années). Certains sont même relativement avancés et nécessitent juste d’être mis en forme ou éventuellement remis à jour avec la dernière version (tellement ils sont vieux).
On m’a gentiment fait remarquer que je n’avais qu’à vous proposer à des personnes qui n’ont pas encore de blog et qui voudraient se lancer de poster sur le blog. C’est une excellente idée ! D’ailleurs, j’héberge déjà les articles de 2 anciens collègues et amis, M4vr0x et ventreachoux85.
Si vous en avez l’envie, n’hésitez donc pas à m’écrire pour voir ce qu’on peut faire ensemble.
Dans tous les cas, qu’il y ait des volontaires ou pas, voilà ce que j’aimerai sortir dans les mois qui viennent (et ya du très très lourd) :
Kubernetes
Sauvegarder votre Kubernetes avec ARK
Grafana et Prometheus par l’exemple : tester l’anti affinité
Utiliser Azure files comme Storage Class dans Kubernetes
Proxmox VE
Créer un cluster Proxmox VE en HA dans le cloud avec Tinc
Snapshots, sauvegarde, réplication dans Proxmox VE
Droit et divers
Quand des anti-linky détournent les résultats d’une thèse sérieuse en instrument de propagande
Que risque-t-on vraiment avec l’abandon de poste ?
Peut on réutiliser un tweet sans l’accord de son auteur ?
Email perso sur boite pro, petite histoire d’une exception
Ce qui a changé
Déjà, j’ai migré le blog sur un cluster Proxmox VE hautement disponible. Avant, on était sur un serveur stand alone avec un autre serveur en standby prêt à démarrer si nécessaire.
Ça peut paraître être un minimum pour un DevOps/SRE/Cloud engineer/whatever, mais vous le savez aussi bien que moi, ce sont les cordonniers les plus mal chaussés
Ensuite, j’ai créé un compte dédié pour le blog sur LinkedIn et Facebook. Et depuis peu, j’ai aussi ouvert des comptes sur Mastodon (@framapiaf.org/@zwindler_rflx pour le blog, @framapiaf.org/@zwindler pour moi) pour relayer la bonne parole à ceux qui ont désertés les plateformes fermées :).
Ce qui va changer
Plusieurs choses, si j’arrive à m’y atteler. J’ai pour projet de …
Me débarrasser de Worpress
N°1 PRIORITY
Sérieusement, j’en peux plus… J’ai besoin d’une 15aine d’extensions, je passe mon temps à les maintenir à jour, les perfs d’affichage sont bof, et ça, juste pour afficher du texte !
J’ai du tweaker le blog, ajouter des caches, analyser les trames et les waterfall views, etc. Alors oui, c’était intéressant de le faire une fois, pour savoir comment ça marche. Mais en vrai, est ce qu’on (nous bloggeurs) se fait pas du mal pour rien ?
De nombreuses personnes sont (re)partie vers des sites statiques (agrémentés d’un moteur de commentaire), qui sont plus que suffisant pour ce qu’on en fait…
Je ne suis pas le seul à faire ce constat, et comme beaucoup, Hugo (gohugo.io) sera très probablement le futur moteur du blog. Je vous tiendrai au courant. Mais bon, vous le verrez vite ;-).
Dégager Google Analytics
Et oui… j’utilise Google Analytics. Pas cool pour les trackers, surtout que je n’ai pas trop le temps d’analyser le trafic entrant pour adapter mon SEO. Soit je m’en débarrasserais totalement, soit je passerai sur Matomo (Piwik) Là encore, d’autres l’ont fait avant moi, rien de foufou (NextInpact entres autres).
Dégager Amazon Partenaires (et Adsense, soyons fous)
Là encore je vais être honnête, je monétise le blog (comme je peux). Ça me paye les frais d’hébergement et me permet (parfois) de payer des VMs pour tester des trucs (Scaleway par exemple) et ainsi écrire de nouveaux articles.
J’ai essayé les dons (via Paypal), ça n’a jamais marché. Le peu que j’ai eu, je l’ai reversé à Wikimedia, tellement c’était ridicule (~10 euros).
En revanche, ce qui marche pas mal, c’est les liens affiliés vers Amazon et les pubs via Google Adsense. Amazon, si je n’approuvais pas trop leur « éthique », je n’approuve plus non plus la façon dont ils traitent leurs clients. Arrêter de consommer chez eux n’aurait pas trop de sens si je continuais par derrière à leur aiguiller des clients.
La 2ème étape est de trouver d’autres méthodes de financement du blog, pour dégager aussi Adsense; et là c’est plus dur.
Depuis peu, j’essaye une nouvelle source de revenu. J’ai enregistré le blog sur Getfluence. Pour faire simple, il s’agit d’un site mettant en relation des marques et des éditeurs pour des articles sponsorisés.
Je vous vois froncer les sourcils. Je n’étais pas du tout fan de l’idée non plus jusqu’à ce que je vois que pouvait imposer MES conditions, à savoir :
Refuser le publi-rédactionnel. C’est MOI qui écris et c’est non négociable
Refuser que la marque relise l’article (et modifie les parties qui lui plaisent pas)
L’information comme quoi il s’agit d’un article sponsorisé est clairement visible
Et bien entendu, refuser les articles qui n’ont rien à voir avec la ligne éditoriale
Et là, ça me gêne moins. Si une marque (type éditeur de logiciel) me contacte pour tester leur outil et que je peux faire un article pour leur donner de la visibilité en tout honnêteté et sans pressions de leur part, je ne vois pas le problème. Et si des lecteurs refusent de lire mon article par dogme car il est sponsorisé, si c’est indiqué clairement, no pressure.
En tout cas, on verra bien si ça prend ou pas.
Si vous voyez une autre méthode ou que vous avez un avis sur la question, je suis bien entendu preneur, même si cette problématique longuement évoquée par d’autres blogueurs (Xhark de Blogmotion par exemple).
Il y a quelques jours, vous avez peut être vu passer dans vos fil d’actus k3s, ce nouveau projet open sourcé par Rancher.
Lightweight Kubernetes. 5 less than k8s.
Il s’agit d’une version réduite de Kubernetes, sans pour autant être minimaliste, qui nous vante la possibilité de monter des clusters Kubernetes avec très peu de ressources nécessaires. On parle de moins de 512 Mo de RAM pour un master, encore moins pour un worker, tout dans un binaire de 40 Mo, support de armhf, et arm64, …
Great for Edge, IoT, CI, ARM, and situations where a PhD in k8s clusterology is infeasible
Cerise sur le gâteau, comme tout est regroupé dans un seul et même binaire, l’installation est ultra simple et se résume en :
Récupérer un binaire
Lancer le binaire sur le master
Lancer le binaire sur le worker avec l’URL du master et un token
Mais c’est génial !
Nécessairement, pour arriver à ça, il a fallut faire quelques concessions mais pour l’instant je ne les trouves pas très gênantes. Parmi les modifications notables, on retrouve :
Suppression des features alpha, legacy et non standard
Suppression de tous les add-on des cloud providers
Remplacement de etcd3 par sqlite3 (même si etcd3 peut être toujours être utilisé)
J’en veux un !
Autant dire que pas mal de bidouilleurs du dimanche se sont jetés dessus.
Le premier exemple qui vient à l’esprit est de monter un cluster Kubernetes sur Raspberry pi. Nombre de personnes ont déjà installé Docker sur un raspberry qui traînait dans un tiroir (moi compris), et le nombre d’articles avec Docker Swarm sur plusieurs Raspberry pullule sur le web.
Tout ça c’est très bien mais jusqu’à présent, il était difficile d’installer Kubernetes sur ce genre de machines, assez limités en CPU/RAM. Du coup, vous vous en doutez, je ne suis pas le premier à parler de ça.
Vincent RABAT aka itwars (que vous connaissez sûrement si vous écumez les meetups sur Bordeaux) m’a coiffé au poteau en releasant un playbook Ansible pour installer k3s, et notamment sur un Raspberry Pi (mais pas que).
A charge de revanche, Vincent ;-).
Un peu différent
Du coup, pour me démarquer, je vous propose aujourd’hui quelque chose d’un peu différent. N’ayant pas suffisament de raspberry sous la main, j’ai voulu faire un PoC de k3s en me basant sur des machines ARM créées chez un cloud provider.
L’idée étant que si ça marche sur des machines de faible puissance en ARM, ça marchera partout (x64, raspberry, etc).
Ça fait plusieurs fois que j’utilise Scaleway comme hébergeur pour des petits projets, et en particulier pour déployer rapidement des machines car leur API est pas trop mal fichues et surtout ils disposent de modules Ansible très bien fait, notamment avec la feature « inventaire dynamique », ce que beaucoup ne font pas.
Pour ceux que ça intéresse, mon talk sur BDX.IO était basé sur le même principe :
Dans ce tuto, je vais donc vous montrer comment en quelque commande, monter un cluster k3s sur des machines ARM créées à la volée chez Scaleway, le tout avec Ansible (vous l’aurez compris).
Pour réaliser ce tuto, je pars du principe que vous avec déjà un compte sur Scaleway, que vous avez un clé SSH qu’on déposera à la racine du projet, appelée admin.pub (c’est original).
Il faudra également installer les package pipy suivant sur la machine locale :
Ensuite, vous devrez installer Ansible depuis les sources (>= 2.8devel) et éventuellement le binaire jq pour requêter dans les output JSON (ça c’est juste pour se faciliter la vie)
Dans la console Scaleway, vous devrez créer un token sur le site de Scaleway pour les accès distants et le stocker dans un fichier scaleway_token
Et enfin sourcer le fichier pour avoir la variable dans votre environnement
source scaleway_token
OK, on est prêt
La première étape de cette procédure va être de générer des instances ARM pour héberger le master et le worker Kubernetes. Pour ça, le playbook Ansible create_arm_vms.yaml va :
récupérer l’ID d’organisation du compte Scaleway
récupérer un ID d’image compatible debian Stretch
ajouter si nécessaire la clé SSH de l’admin
créer autant de machines que nécessaire
On lance la commande suivante :
ansible-playbook create_arm_vms_scaleway.yml
ET C’EST TOUT !
Normalement en 2 minutes, vous devriez avoir 2 instances ARM sur le datacenter de Paris (par1).
A noter, il se peut qu’elles ne soient pas accessibles tout de suite en SSH. J’adapterai peut être le playbook pour qu’il ne rende pas la main tant que les machines ne sont pas accessibles, et qu’on enchaîne automatiquement sur l’étape suivante (TODO).
Inventaire automatique
Je le disais plus haut, la grande force de Scaleway avec Ansible est le fait qu’ils ont fait l’effort de coder l’inventaire dynamique. Vous n’avez pas besoin de renseigner à la main les IPs des instances que vous venez de créer dans un fichier ansible/hosts. Grâce à l’API, la découverte se fait automatiquement. On va dont pouvoir enchaîner sur la suite directement.
De base, voici le contenu de mon fichier d’inventaire (inventory.yml) :
Une étape qui est souvent fastidieuse, surtout quand on ajoute beaucoup de serveur, est l’étape de vérification de l’empreinte SSH des nouveaux serveurs lors de la première connexion. Cette authentification est très importante et il n’est pas du tout conseillé (comme je le vois parfois) d’ajouter l’option ANSIBLE_HOST_KEY_CHECKING=False.
Ici, je vous propose de scanner automatiquement la première fois l’empreinte, et l’ajouter dans votre known_hosts. Ainsi, si l’empreinte change en cours de route, vous serez prévenus. Cependant, ce n’est à utiliser que dans le cas de notre bidouille, pas en production.
Vous pouvez maintenant ajouter votre clé SSH dans le ssh-agent, et vérifier qu’on vous pouvez vous connecter à tous les serveurs via Ansible :
eval `ssh-agent`
ssh-add myprivate.key
Préparation du serveur
C’était facile, non ?
Et bien la suite l’est encore plus, à l’exception de cette petite subtilité/piège => Il se trouve que l’image ARM par défaut proposée par Scaleway ne dispose ni de python ni de sudo. Pour faire du Ansible, c’est très très handicapant.
J’ai donc écris un petit playbook, à n’exécuter la première fois, qui installe les prérequis non présents sur l’image de base (python et sudo)
Le cluster est maintenant opérationnel. Les serveurs ont Kubernetes installé et fonctionnel. Le ou les workers ont rejoint le master et font parti d’un même cluster. Un Ingress controller Treafik est créé, on peut jouer dessus directement
Bonus : accéder au cluster
Bon je vous ai un peu feinté.
Certes, on peut se connecter en SSH sur le master et le piloter avec les commandes kubectl classique (mais il faut rajouter k3s devant car le binaire kubectl est intégré à k3s). Mais c’est quand même plus simple si on peut y accéder à distance, depuis votre machine locale.
Là encore, j’ai donc fais un petit playbook qui va aspirer la configuration kubectl et la coller dans le fichier ~/.kube/config.k3smaster
A partir de là, vous devriez pouvoir tester votre nouveau cluster depuis votre PC
cd
kubectl --kubeconfig=.kube/config.k3smaster get nodes
NAME STATUS ROLES AGE VERSION
k3smaster1 Ready <none> 2d v1.13.3-k3s.6
k3sworker1 Ready <none> 2d v1.13.3-k3s.6
Note : Il ne s’agit pas d’un article sponsorisé. Pour être honnête, j’avais des questions techniques et Shadow/Blade a même refusé de me répondre ;-p. Vous pouvez donc lire cet article sans craindre que j’aie été influencé.
En fait, ce sujet m’intéresse depuis le début du blog et mes premières bidouilles en 2010. Un des objectifs que je m’étais fixé était de pouvoir avoir une plateforme mutualisant à la fois mon serveur avec ses VMs ainsi qu’une plateforme de jeu, dans une même boite. L’idée était d’avoir juste un écran/clavier/souris ou un portable, n’importe où dans la maison, et de déporter le bruit et la chaleur dans une pièce, plus loin.
A l’époque, j’avais monté une plateforme de virtualisation, idéale pour le serveur, mais pas trop pour une plateforme de gaming déportée. Dans les soucis que j’avais rencontré, la partie virtualisation de GPU et/ou GPU paththrough était un peu capricieuse, et surtout, le plus gros souci de l’époque, étaient les protocoles de streaming.
Clairement, on n’avait pas ce qu’il fallait pour streamer efficacement et facilement un jeu, même en LAN (malgré quelques avancées chez Citrix et Microsoft avec 2008r2).
Un peu plus tard, le streaming by Steam et NVidia
Quelques années après, Steam a carrément cassé la baraque en apportant la possibilité de streamer des jeux d’un PC à un autre dans la maison. Sur un LAN Ethernet, les contrôles sont fluides, l’image aussi, et j’ai rencontré très peu de bugs. Côté streaming, c’était clairement gagné. On peut aussi noter le NVidia Shield, qui apporte une expérience similaire, mais qui nécessite d’acheter le produit (c’est pour ça que je ne l’ai jamais testé, mais ça marche bien a priori).
Mais il me manquait encore un petit quelque chose. J’avais encore besoin d’avoir un PC séparé pour le jeu et un autre pour les machines virtuelles, ne sachant toujours pas comment mutualiser le jeu et la virtu (voire de virtualiser le GPU dans une VM).
Et vint Shadow
Clairement, j’avais laissé de côté cet objectif. Et puis, au fil du temps, est arrivé fin 2017 Blade, avec son service Shadow. La promesse, alléchante, était : avoir un PC gamer haut de gamme, évolutif au fil des années, sans avoir à acheter/installer du matériel haut de gamme.
Plus besoin de hardware : ton Shadow tient dans une simple application. Un PC complet avec des performances haut de gamme, accessible sur tous tes écrans, en un clic.
Comme nous prenons en charge le hardware, ton Shadow n’est jamais obsolète. Processeur, carte graphique, mémoire… Ta configuration est mise à jour régulièrement
Si on regarde la fiche technique telle qu’elle est disponible aujourd’hui (https://shadow.tech/discover/specs), pour ~30€ par mois avec une offre d’engagement, on peut avoir une machine avec une GTX 1080, 8 threads dédiés (Xeon), 12 Go de DDR4 et 256 Go de stockage SSD. Shadow s’adresse donc bien, a première vue, à un public gamer relativement haut de gamme.
2ème point important, si Shadow -et plus généralement le cloud gaming- ont un peu de mal à percer, c’est notamment car de nombreuses personnes n’avaient pas de connexion suffisament stable, avec une faible latence et un débit suffisant pour jouer dans de bonnes conditions.
Si sur de la diffusion type IP-TV, on peut se contenter d’un flux avec un peu de différé pour absorber la latence et la gigue, voire pour optimiser la bande passante, et ainsi permettre à ceux qui ont peu de débit d’en profiter.
Ce n’est évidemment pas possible pour un jeu vidéo, où l’expérience utilisateur sera dégradée, même pour le moins exigeant des gamers, dès ~50 ms (et bien moins pour les plus exigeants).
Avec une latence souvent inférieure, beaucoup plus stable, et des débits très largement suffisant pour passer un flux vidéo même peu compressé, la fibre semble donc être un prérequis (on y reviendra) à Shadow.
Comparer ce qui est comparable
Maintenant que c’est dit, revenons à mon expérience Shadow, par rapport à mon expérience de jeu habituelle.
Et ça tombe super bien, parce que c’est à peu de choses près la configuration Gamer que j’ai chez moi également (i7 gen4, GTX 1080, 16 Go de RAM, SSD). On est donc sur des machines comparables sur le papier.
En réalité, il y a probablement de grosses différences entre une machine bien ventilée et dédiée sous son bureau et une VM (ou une machine physique ?) avec un GPU dans un rack, et qui accède à une baie de disque SSD partagée par des centaines de personnes.
Crédits : Blade
Pour finir, la raison qui m’a vraiment décidé à tester récemment, c’est parce que j’ai enfin la fibre chez moi ! A moi les connexions rapides et stables (ENFIN!).
Économiquement, est ce que ça tient la route ?
Je ne suis (vraiment) pas le premier à tester Shadow (je vous ai laissé en fin d’article une petite compilation des blogs que j’ai lus avant de me décider de tester le service), mais un point que je n’ai vu dans aucun article, c’est l’analyse du prix.
Cette analyse est très difficile à faire car elle dépend de beaucoup de facteurs subjectifs, notamment sur la durée de vie et d’amortissement du matériel. Pour certains, un GPU ne dure pas plus d’un an quand d’autre le garderont jusqu’à ce qu’il tombe en panne ou soit réellement obsolète dans 10 ans. On peut aussi compliquer le problème en partant du principe que le matériel vieillissant peut être revendu !
Je suis donc parti sur les hypothèses suivantes :
J’ai profité d’une promotion pour Shadow à 30€/mois sans engagement. Cependant, vous pouvez obtenir un prix similaire hors promo en vous engageant sur 1 an
J’ai estimé le prix des composants de mon PC (similaire à Shadow en terme de caractéristiques) au moment où je les ai acheté
Je garde mes composants environ 5 ans, sauf le boîtier et le ventirad (10 ans), après quoi je considère que leur valeur résiduelle est négligeable (ils peuvent même être tombés en panne et remplacés hors garanti AVANT les 5 ans)
Ça peut paraître anecdotique, mais avec Shadow, vous allez faire des économies d’électricité, puisque vous pouvez vous contenter d’un PC basse consommation. J’ai donc estimé la consommation électrique de ma machine de guerre et j’ai multiplié cette quantité d’électricité par 4h de jeu / semaine
Voilà le détail du calcul :
Avec MES hypothèses, on tombe donc sur un prix sur 5 ans relativement similaire à l’achat d’une machine montée soit même, avec les composants achetés à l’unité et durant 5 ans.
D’un point de vue purement économique, la bonne nouvelle est donc que Shadow est totalement pertinent par rapport à l’achat d’un PC haut de gamme..
Qualité vidéo
Maintenant que c’est dit, on peut s’attaquer au ressenti utilisateur, en commençant par la qualité du flux vidéo.
Comme je l’ai dis plus haut, contrairement à de la TV sur IP, le stream de jeu doit être le plus rapide et fluide possible. On ne peut pas perdre trop de temps à compresser de manière optimale le flux. Cela induit donc des protocoles nécessitant peu de calculs (et donc potentiellement moins perfectionnés) et des bandes passantes importantes.
Ça va être difficile de vous « montrer » la différence entre l’image réelle et l’image affichée sur mon écran. Je ne vais pouvoir parler que de ressenti.
Mon ressenti (personnel donc), quand j’ai lancé pour la première fois Shadow, est une image un peu baveuse; ce n’est pas aussi net qu’en local.
Mais ce n’est qu’une impression, car en regardant en détail, je n’ai rien pu déceler de visible, en me concentrant sur une partie de l’écran par exemple. Les caractères paraissent nets, il n’y a pas d’artefacts liés à une compression (comme quand on compresse trop un JPG par exemple).
Mais dès la première heure de jeu, je ne le voyais plus. A un tel point, que je me suis finalement dis que j’avais du me tromper, que c’était un biais cognitif… jusqu’à ce que j’arrête d’utiliser le Shadow !
Dès que je suis retourné jouer exclusivement sur mon PC, j’ai tout de suite senti une image plus nette, sans réussir à expliquer pourquoi.
Je précise que je joue sur un 29 pouces extra large (21:9ème) en 2560*1080. Je ne peux donc pas dire quel impact cela a par rapport à une configuration plus classique en 16:9ème (qu’on soit en Full HD ou plus). Certaines personnes avec des résolutions plus élevées (et donc plus rares) ont eu des retours plus ou moins positifs.
Cette résolution n’a posé aucun problème (parfois le cas sur des protocoles de streaming/prise en main à distance).
Bande passante
La première chose à faire lorsqu’on lance le client Shadow sur un nouveau device est de lancer un test de connexion.
Grosso modo, vous pouvez fixer une bande passante maximale, jusqu’à 50 Mb/s, ou choisir le test de connexion, qui vous permettra, le cas échéant, d’avoir jusqu’à 70 Mb/s (mon cas).
Récemment, Blade a communiqué sur une nouvelle fonctionnalité du Shadow => la possibilité d’utiliser le protocole H.265 sur des machines récentes (capable de le décoder nativement), pour réduire la bande passante et ainsi permettre aux gens disposant d’une connexion ADSL/VDSL de bonne qualité d’en profiter.
Dans l’interface Shadow, il est question d’un « Mode faible connexion ».
Je trouve cette terminologie étonnante. sur le papier, le protocole H.265 est très probablement un bon protocole, AUSSI pour les bonnes connexions.
Pour autant, effectivement, en faisant des tests, je n’ai pas trouvé d’amélioration à passer sur ce protocole, voire même des dégradations dans la netteté (là encore, c’est du ressenti).
Le point le plus visible que je peux vous montrer, sont les caractères sur fonds blancs dans l’explorateur Windows autours desquels ont peut déceler un léger halo rouge :
En plus de ça, en consultant les stats, je n’ai pas remarqué un réel gain en terme de bande passante par rapport au protocole standard….
Je ne me l’explique pas vraiment, mais cela explique très certainement pourquoi Shadow ne le met pas en avant, avec cette dénomination que je trouve un peu « péjorative ». A voir si ça s’améliore dans le futur.
Réactivité des contrôles, latence
C’est là où je m’attendais à un gros flop et j’ai vraiment été bluffé. Avec une latence entre chez moi (Bordeaux) et les datacenters de Blade (hébergés par Equinix, près de Paris) à 20 ms (très stable), je m’attendais à être capable de déceler un lag, notamment sur les jeux multijoueurs.
Crédits: Blade
En réalité, après avoir joué en ligne à Star Wars Battlefront 2, une partie de la latence induite par l’aller-retour entre chez moi <=> DC de Blade est probablement compensée par le fait que les serveurs de jeu sont plus près. Le tout étant masqué par le « netcode », je n’ai ABSOLUMENT pas vu d’impact sur le jeu, même en FPS/multijoueur.
Les plus hardcores d’entre vous qui cherchent le moindre ms pour sniper dans CS:GO ou qui vivent dans un datacenter seront bien entendu vent debout contre cette affirmation. Cependant, dans mes conditions de jeu, à mon échelle de semi-casual vivant en province, je n’ai pas réussi à voir de différence ! C’est vraiment bluffant.
Autres configurations du client
Au delà du protocole vidéo, le client Shadow propose un grand nombre d’options et de fonctionnalités (expérimentales, ou pas), c’est très agréables. Je ne les ai d’ailleurs pas toutes essayées.
Un des gros points gênant pour Shadow -jusqu’à il y a peu- était le fait qu’il n’y avait pas moyen de passer le son du microphone quand vous aviez un micro-casque jack. C’est normalement corrigé, comme vous pouvez le voir, avec le support Expérimental de l’option.
Personnellement, ayant plusieurs plusieurs périphériques USB (micro-casque, contrôleurs, …), la fonctionnalité de « forwarding USB » a parfaitement fonctionné. Aucun bug à remonter.
Et sur d’autres écrans ?
Dans sa publicité pour Shadow, Blade met en avant le fait qu’on peut jouer n’importe où. Sur le papier, l’idée séduit, une fois de plus : c’est tout l’avantage du cloud, plus besoin d’amener sa tour en déplacement, un simple PC portable suffi(rai)t.
Dans la pratique, ce n’est évidemment pas si facile. S’il existe une application Apple et Android, je vois mal qui jouerait un jeu PC sur un iPad, encore moins sur un smartphone. En terme d’ergonomie, utiliser un PC sur une tablette à toujours été un peu fantaisiste, encore plus dans un contexte du jeu.
Quant au PC portable, il va falloir avec :
1) Une bonne connexion sur le lieu où vous voulez accéder à Shadow. On en revient toujours au même => pas de Fibre = risques de problèmes à prévoir
2) Attention à la connectivité Wifi ! J’ai eu une expérience catastrophique (injouable) avec le wifi (N) de ma Freebox v6. Le wifi AC est d’ailleurs fortement conseillé par Blade si vous n’avez pas le choix. Gardez en tête que c’est quasiment ethernet (sans CPL si possible) ou rien si vous voulez éviter de vous faire peur.
Avec ces 2 contraintes, ça limite donc grandement les lieux éligibles à l’accès à votre plateforme Shadow en mobilité…
Au delà du jeu
Un point qu’on oublie quand on compare Shadow aux autres offres de cloud gaming est le fait que Shadow est une VM dédiée dans le cloud.
C’est VOTRE Windows. Rien ne vous empêche donc de l’utiliser pour autre chose que jouer.
Vue la puissance du bouzin, vous pourriez très bien héberger des serveurs quand vous ne jouez pas. Pour autant, j’ai du mal à voir le cas d’usage, puisque la machine est éteinte quand vous ne l’utilisez pas…
Autre idée, on pourrait en faire une plateforme de téléchargement pour de gros fichiers. Je vous voit arriver avec vos gros sabots (et Blade aussi) => dans une interview, il était questions de surveiller les trafic upload/download anormaux par rapport à la charge. Mais dans tous les cas, vu le prix, on ne peut pas dire que Shadow soit une offre idéale pour faire une seedbox…
Conclusion
Je me suis déjà beaucoup étalé sur Shadow, et je trouve que c’est un produit super. Vient donc le temps d’arrêter d’en rajouter et de faire un petit résumé.
Techniquement, Shadow est un produit qui fonctionne, à un tarif cohérent. Le pari de fournir une machine dans le cloud pour remplacer un PC coûteux est tenu, dans certaines limites.
Les joueurs les plus acharnés trouveront que la latence ou la (très légère) dégradation de l’image n’est pas acceptable
Beaucoup d’utilisateurs se plaignent des performances du stockage, certes sur des baies SSD, mais probablement trop sollicité par rapport au nombre d’utilisateurs
La promesse de pouvoir jouer partout est purement marketing // sans connexion fibre (ou VDSL très stable) et full Ethernet, point de cloud gaming ; c’est la vie
Ça fait un bon moment que le Shadow fonctionne avec une GTX 1080. Difficile de tenir la promesse « d’un PC toujours à jour » quand NVidia sort des GPU aussi cher que les RTX…
Personnellement, quand j’ai démarré l’abonnement, au vue du prix et des fonctionnalités proposées, je me suis réellement posé la question d’abandonner mon PC fixe et de ne garder que Shadow. Mon objectif était de vendre ma tour et de jouer sur mon portable, via Shadow.
Après un mois d’utilisation, j’ai résilié l’abonnement. Cependant, j’insiste : ce n’est pas parce que Shadow est un mauvais produit. Shadow est un produit abouti et stable.
Cependant, il ne faut pas non plus se voiler la face, Shadow n’est pas à la hauteur d’une machine physique avec un i7 et une GTX sous votre bureau.
En revanche, si demain, mon PC tombe en panne, la question se reposera (très sérieusement). Mais en l’état, je préfère garder ma machine de guerre ;).
Au cas où le titre de l’article n’aurait pas été suffisamment clair, il s’agit d’un billet d’humeur comme je m’en autorise rarement sur le blog… Mais sans plus attendre, rentrons dans le vif du sujet : Depuis le 31 mars (ce n’était pas une blague du 1er avril), nous avons appris la nomination de Cédric O comme secrétaire d’état en charge du numérique.
Pour ceux qui n’auraient pas suivi, il succède à Mounir Mahjoubi, qui a décidé de briguer la mairie de Paris.
Mais comment s’est passé la nomination ??
En voilà une bonne question. Jusque là, donc, je n’avais pas d’avis sur cette personne. Cependant, au détour d’un tweet, voilà ce que j’apprends :
Quand un homme chargé de suggérer le nom de 4 femmes pour un poste ministériel aux deux hommes au pouvoir préfère… se suggérer lui même, on se dit que le patriarcat a de beaux jours devant lui dans le numérique et que la parité promise a du plomb dans l’aile ! #remaniementpic.twitter.com/JEiSeth05J
Pour ceux qui souhaitent comme moi vérifier l’article d’origine quand on lit une capture d’écran, le tweet pointe vers cet article de frenchweb.fr.
Un passage retient particulièrement l’attention :
Dans un premier temps, quatre candidates étaient pressenties : Aurélie Jean, Paula Forteza, Olivia Grégoire et Amélie de Montchalin.
Selon nos informations, un retournement de situation aurait eu lieu avec la sélection du sélectionneur par lui-même.
D’autres voyaient plutôt Paula Forteza, dans un autre style, mais tout aussi légitime pour le poste. Avant l’annonce de la nomination, de nombreux articles allaient dans le sens de l’une ou de l’autre.
Mais pourquoi donc a-t-on préféré Cédric O, plutôt que ces femmes là ?
Tout de suite, l’idée qui vient à l’esprit est « pourquoi manquer une occasion de nommer une de ses femmes brillantes et qualifiées, pour propulser un inconnu dans le devant de la scène ? Peut être que Cédric O était un encore meilleur candidat ! »
OK. Qui est Cédric O, qu’a-t-il fait avant ?
Un rapide tour sur Wikipedia permet d’apprendre qu’il est diplômé d’HEC. Un vrai expert du numérique de formation, donc. Pour info/rappel, Mounir Mahjoubi sortait de Sience Po, donc au final, les cyniques diront que ça ne change pas grand chose.
Ensuite, il s’est engagé en politique avec d’autres proches du président (dont certains qui ont fait parler d’eux récemment, dont Ismaël Emelien) à l’époque DSK, puis chez En Marche, où il a été trésorier. Là encore, un poste idéal pour un futur secrétaire d’état chargé du numérique.
Quel rapport avec le numérique ?
Il suffit de taper « Cédric O » et « geek » dans votre moteur de recherche préféré pour voir la flopée d’articles qui sont sortis sur lui (tous pompés les uns sur les autres) depuis. On essaye donc de nous faire croire qu’il est qualifié pour le poste car… c’est un geek.
Un peu comme quand Mounir Mahjoubi nous expliquait qu’il avait passé son adolescence sur IRC. Ça nous fait une belle jambe.
Alors d’accord… je suis très critique alors qu’il fera peut être très bien le job.
Mais bon … Quelle occasion gâchée d’avoir au numérique des femmes charismatiques, qui savent de quoi elles parlent, pouvant servir de « role model » pour des jeunes filles, alors qu’on sait qu’elles se détournent toujours plus du numérique. Ça me rappelle cruellement le talk d’ouverture de BDX.IO 2018 d’Audrey Neveu – The Hitchhiker’s Guide to Diversity (Don’t panic!).
Je note d’ailleurs la réaction assez molle de toute la classe politique et tous les « experts » qui peuplent la twittosphère et qui étaient bien plus inspirés par la nomination de Sibeth Ndiaye (mais c’est une autre histoire). Hormis le tweet que j’ai cité en début d’article, pas ou peu de réaction.
Cédric O a une sœur
Pour finir et faire écho à mon titre, s’agit-il de sexisme ordinaire comme le sous-entend le tweet de CodeForFR, ou y a-t-il une autre raison ?
La raison qui fait de Cédric O un candidat plus désirable que toutes ces femmes dont on parle depuis le début, se trouve peut être en dernière ligne de cet article de NextInpact :
Mounir Mahjoubi va maintenant retrouver son poste de député, récupérant le siège qu’il avait laissé à sa suppléante, Delphine O, sœur de Cédric O.
Permettez donc moi un petit moment de fiction de mon propre cru, sur ce que je pense qu’il s’est passé, fin mars.
Allo, Delphine ? Désolé, je suis plus ministre… Ben… du coup, ça veut dire que je reprend mon siège… Ouais je sais, c’est pas cool.
Mais ne t’inquiètes pas, en échange, je pousse ton frère comme mon remplaçant. Comme ça on est quittes.
France (@SAPFrance) 
