PROJET AUTOBLOG


Le blog de Seboss666

Site original : Le blog de Seboss666

⇐ retour index

J’ai besoin de changer de souris gaming !

mercredi 8 janvier 2020 à 18:30

Après avoir changé le PC, dont l’ancien fait le bonheur des soirées de mon beau-frère, il se trouve que ma souris commence à montrer des signes de faiblesse, avec un clic gauche qui commence à ne plus répondre (et plus récemment le clic droit). Mais j’ai du mal à choisir un nouveau modèle, du coup, voyons la réflexion sur mes besoins.

La souris actuelle

J’ai une vénérable Razer Deathadder 3,5g achetée en 2012. Elle est venue remplacer une cousine, de marque Microsoft. Oui, à une époque Microsoft avait tenté de proposer sous son propre nom des périphériques gaming en partenariat avec d’autres marques, et c’était Razer en l’occurrence (et la souris, c’était la Microsoft Habu). Mais elle avait vieilli un peu vite à mon goût avec un clic gauche qui en faisait plusieurs d’un coup.

La remplaçante n’a jamais vraiment eu ce problème, mais par contre, au bout de sept ans, elle donne elle aussi quelques signes de faiblesse, avec des clics qui parfois ne répondent plus. Et puis ça fait des années que je suis contraint de m’en servir sans driver, car Synapse est une horreur qui ne fonctionne pas sans création d’un compte chez Razer, pas stocké en Europe pour sûr, ce qui n’a strictement aucun sens pour un périphérique, à moins de vouloir faire des trucs pas jolis (oui je sais, synchro « cloud » des profils toussa, juste non).

Il est donc temps de changer, et là remplaçante doit, à l’image de mon smartphone, tenir un certain cahier des charges.

La check-list

Je vais lâcher la liste tout de suite et on va détailler le raisonnement pour chaque point, ça sera plus sympa. Donc :

Voilà, je demande pas non plus la lune je pense, comparé au smartphone où on l’a vu j’avais d’ailleurs fait pas mal de concessions. Alors on détaille ?

Pilote propre

Je l’ai déjà évoqué, mais un pilote de souris qui a besoin d’un compte en ligne déborde définitivement de son rôle, et devient pour ma part éliminatoire. En dehors de l’usure c’est le seul grief que j’ai à l’encontre de ma souris actuelle, c’est dire à quel point ce modèle me plaît. Il est donc exclus de prendre sa petite sœur, rien que pour cette raison.

Le pilote doit faire juste ce pour quoi il est prévu : gérer les paramètres de sa souris, pourquoi pas gérer des profils différents en fonction des jeux, comme les pilotes graphiques qui vous permettent de manipuler certains paramètres de rendu pour optimiser les performances et/ou la qualité visuelle. Les paramètres en question concernent les paliers de sensibilité du capteur, le mappage des boutons (on peut « affecter » des touches claviers ou des actions spécifiques à certains boutons), la gestion de la « luminosité » (j’y reviendrai), voilà normalement juste ce dont on a besoin.

Évidemment si on peut s’éviter de bouffer 200Mo de RAM pour ça ce sera tout bénef. Ce n’est pas parce qu’on est obligé d’être large sur ce point à cause de Windows et des jeux récents qu’il faut en abuser, les lanceurs de jeux et les navigateurs s’en chargent déjà trop bien (ou mal c’est selon).

Plusieurs boutons, programmables si possibles

Les souris possèdent depuis longtemps au moins trois « boutons », c’est à dire les clics droit et gauche, ainsi que le clic « molette ». Il est assez courant d’avoir également des boutons qui par défaut déclenchent les actions précédent/suivant des logiciels les proposant, navigateurs Web en tête. Ces boutons « 4 et 5 », quand ils sont bien placés sur la souris, sont bien pratiques pour effectuer certaines actions qui demanderaient de déplacer un de nos doigts au clavier et donc réduire nos capacités de déplacement.

J’ai tendance à considérer que ces 5 boutons ne sont plus forcément suffisants ou adaptés, un ou deux de plus, facilement accessibles, ne seront pas de trop. Et si on peut aller au-delà de l’affectation dans les jeux pour déclencher des actions en dehors, les programmer quoi, c’est banco.

Pas besoin d’en arriver là non plus hein 😀 (crédit : gamertech.fr)

Bon support Linux ?

Après avoir vu que ces dernières années la situation avait bien évolué, je serai pas contre retrouver les mêmes capacités sous Linux, histoire de pousser un peu plus Windows vers la sortie si un jour c’est vraiment possible.

Et on ne parle pas juste de module/pilote noyau là, ou juste une bibliothèque et un outil en ligne de commande, mais bien d’interface graphique avec une ergonomie suffisante pour ne pas faire fuir les néophytes de l’OS. C’est beaucoup trop fréquent d’avoir un outil génial, puissant, mais dont l’ergonomie et même juste le design réalisé par un enfant de six ans. On ne sera certainement pas au niveau des pilotes Windows officiels, mais ça doit rester utilisable.

Pas de RGB, une souris c’est pas un sapin de Noël

Je sais qu’il y a des chances que ce soit un vœu pieu, mais cette mode de merde sur le matériel estampillé gaming me gonfle particulièrement. Je l’ai déjà évoqué et particulièrement bien esquivé dans le projet du nouveau pc.

Ma souris actuelle a un logo et un liseré bleu clignotant qu’il est possible de désactiver via le pilote (ou plutôt était possible, hein), ma souris sans fil chinoise à 15 balles permet de faire ça avec le bouton d’alimentation sans pilote. Donc même si finalement je ne peux pas échapper à cette horreur, il faut que ça soit désactivable sans perdre 20 minutes à chaque fois. Ce point est éliminatoire.

Ça, c’est pas possible. Non. Pitié.

Design et poids

Quant au design, je ne suis pas partisan des audaces à base de modules détachables, la durabilité de la souris doit être exemplaire. Plus il y a de parties mobiles, plus la souris fera de bruit, c’est comme le clavier faut pas abuser. Après vous avez vu la death adder, vous voyez le gabarit et le type de design qui me botte en premier lieu, mais si un design différent s’avère tout aussi confortable, go.

La question du poids ajustable est vraiment minoritaire, je n’ai jamais eu l’occasion d’essayer et je sais que ce n’est pas réservé à des souris ultra haut de gamme. Une nouvelle expérience quoi ?

Budget raisonnable

Je ne suis plus un gros core gamer comme j’ai pu l’être à une époque, je ne me vois donc pas mettre 150 balles dans une souris. Mais je sais que pour jouer longtemps dans de bonnes conditions, il faut tout de même y mettre un début de budget. Entre 60 et 70 € ne me paraît pas déconnant pour identifier des modèles qui collent plus ou moins au reste de la check-list. Si ça déborde un peu mais que l’élue est parfaite pour mes besoins, ça se discute évidemment.

Verdict ?

Je garde cet article pour recueillir les modèles que vous pourriez identifier et partager en commentaires, je continue aussi de mon côté les recherches en me basant sur ces critères. Et on discutera du choix final une fois acheté, testé. Je suis pas fan de faire juste de l’unboxing ?

Bonne fin du monde 2020 ?

dimanche 5 janvier 2020 à 17:00

Je viens de vérifier, j’avais pas fait de vœux pour 2019; en même temps, j’étais un peu concentré à devoir rapprendre à marcher, et à vous présenter le bonheur de retrouver une connexion internet fonctionnelle chez ma maman, après quatre ans de galère. Mais bon, de toute façon, vu comment s’est déroulée cette année écoulée, que ça soit en France ou de manière générale autour de la planète, hein, on va pas dire que ça servait à grand chose.

En vrai il y a peu chances qu’une fin du monde se produise, mais bon, étant donné que notre société craque de toutes parts à cause de dirigeants toujours plus déconnectés de la réalité du quotidien de la majorité de la population — et pas qu’en France, je vous « rassure »  — , ça serait pourtant pas si déconnant comme « souhait ».

Autant dire que le futur ne s’annonce pas avec un optimisme rayonnant. J’en viens à croire qu’il ne faudra qu’un effondrement global, et une réduction drastique de la population mondiale, donc vous imaginez que j’essaie d’y penser le moins possible parce que ce genre d’évènement ne se passera pas bien, et tous les auteurs de science-fiction et d’anticipation ont déjà eu pas mal d’idées pour décrire le résultat.

Est-ce que ça m’empêche de vous souhaiter tout le bonheur du monde ? Certainement pas, déjà j’ai conscience que je m’attache à certains détails dont je peux voir des conséquences qui mettront des années à devenir réelles, mais à force de voir quantité de signaux faibles, le tableau que je dresse mentalement ne fait vraiment pas envie. En changeant d’échelle voir de point de vue, il y a pourtant quantité de rayons de soleil qui traversent les nuages qui surplombent mon esprit, et leur chaleur est particulièrement réconfortante. S’il y avait une bonne résolution à tenir, ça serait de trouver le moyen de focus sur ces points. Profitez donc de tout ce que vous trouverez de positif, tirez les bons enseignements et ne vous attardez pas trop sur les évènements négatifs qui vous arriveront, en dehors de ce que vous pourrez en apprendre, je vous jure que ça bouffe du temps dans une vie bien trop courte pour la gâcher. Faites ce qui vous plaît, évidemment tant que ça veut pas dire de pourrir quelqu’un d’autre.

Faites des rencontres, un des mes objectifs de 2019 était d’améliorer ma sociabilité, le peu que j’ai réussi à faire a été plaisant et permet d’ouvrir les esprits (les gens en face vous découvrent autant que vous les découvrez), même si ça reste compliqué. Mieux encore, il faudrait que je fasse plus de rencontres féminines, oui je sais, mais je bosse dans un environnement majoritairement masculin et parfois, ben c’est super lourd. Les femmes dans presque tous les domaines de l’informatique manquent beaucoup, on sait largement pourquoi, que ce soient les stéréotypes dès les plus jeunes années où on leur dit « c’est pour les garçons », qu’avec l’environnement pénible et sexiste, disons-le franchement, une fois passée l’adolescence. Et je m’excuse d’avance si je ne suis suffisamment vigilant parfois quand je participe moi-même à cette ambiance.

Enfin voilà, vous l’aurez compris, je vous souhaite le meilleur, sauf aux plus gros débiles de tous bords qui pensent qu’agresser les autres est un mode de vie enviable, avec l’espoir que 2020 réveille quelques consciences pour améliorer le tableau d’un monde bien mal en point.

Ce clip est à l’image de ce qui se passe actuellement

Une bonne gestion des volumes NFS dans un cluster Docker Swarm

mardi 10 décembre 2019 à 18:30

Quand j’ai monté mon cluster chez moi sur le micro serveur, j’ai fait pas mal de boulettes, au final, l’une des seules qui mérite encore vraiment des claques c’est ma gestion des volumes persistants. J’ai donc pris le temps de chercher comment tout refaire, et de vous partager tout ça car c’est pas si trivial, et ça a pris du temps pour tout identifier.

Pas besoin de rappeler qu’il vous faut des volumes pour gérer les données persistantes de vos containers docker. L’outil dispose même d’une fonction native, avec une extensibilité certaine pour pouvoir gérer tous les types de stockage possibles.

Mais quand je découvre un truc j’ai toujours tendance à commencer par faire de la grosse merde, et en l’occurrence je ne me suis pas servi tout de suite de cette fonction. À la place, j’ai créé un « gros » partage global sur mon NAS, que j’ai monté ensuite dans un dossier sur chaque machine du cluster; chaque « volume » est un dossier dans ce partage, et j’ai indiqué dans la déclaration de la stack le chemin vers ce dossier. Ouais je suis comme ça, parfois.

Mais j’avais un gros problème avec ça : lors de micro-coupures de courant, le serveur redémarre en moins de 30 secondes, pareil pour les VMs du cluster qui du coup tentent de relancer tous les services. Sauf que le NAS met trois bonnes minutes à démarrer, ce qui fait que les VMs démarrent sans leurs volumes, et donc les containers n’ont pas leurs données. Au mieux, ça redémarre à blanc, au pire ça plante en boucle. Quand tout est revenu, il faut que je redémarre chaque VM pour rétablir le service (j’ai même fait un playbook ansible pour ça…)

Docker volume et NFS, foire à la saucisse

L’idée est donc de conserver ces partages, mais de les redéfinir en tant que volume Docker, on sépare ainsi la gestion des volumes de celles des stacks, c’est plus propre, ça réduit la dépendance à l’OS sous-jacent, enfin bref, vous avez compris à quel point c’est mieux.

Au début, vu le peu de documentation je pensais qu’il fallait un plugin pour gérer quelque chose d’aussi basique que le NFS, j’avais même commencé à écrire le brouillon de cet article en ce sens. Et en fait non c’est bien géré en natif, ça a juste une « forme » dégueulasse. Tellement dégueulasse que rien que pour la déclaration des volumes, ça m’a pris plusieurs essais, notamment parce que contrairement aux services, les volumes déclarés dans une stack ne sont pas supprimés avec elle. Et si vous tentez de redéfinir un volume existant, ben il n’en tient pas compte et garde la définition existante. Qui est probablement moisie. Il faut donc, entre chaque essai, supprimer les volumes fautifs sur tous les nœuds du cluster.

Pratique non ?

Passons à la pratique

Attention, pensez à bien tout sauvegarder avant, on est jamais a l’abri d’un effet de bord malencontreux lorsqu’on modifie un stockage avec donc des permissions particulières.

Commençons par détailler l’existant. Pour l’exemple je vais prendre les volumes de smokeping, c’est le moins critique de tous. Voici le partage sur le NAS :

Et sur chaque vm, j’ai un dossier monté via /etc/fstab :

ip_nas:/Docker /home/seboss666/docker nfs _netdev,nfsvers=3,defaults,user,exec 0 0

Aucun commentaire sur le chemin de destination s’il vous plaît 😀 Quant à la stack, les volumes sont déclarés et utilisés de la sorte :

version: "3"

networks:
  smokeping:
    driver: overlay

services:
  smokeping:
    image: linuxserver/smokeping:191068eb-ls64
    networks:
      - "smokeping"
    ports:
      - "20080:80"
    environment:
      - "PUID=1001"
      - "PGID=1001"
      - "TZ=Europe/Paris"
    volumes:
      - /home/seboss666/docker/smokeping/data:/data
      - /home/seboss666/docker/smokeping/config:/config
    deploy:
      replicas: 1
      restart_policy:
        condition: any

Comme je l’ai dit, basique mais ça fonctionne, mais c’est pas pour autant que je suis content de cette situation. Le mieux est quand même de pouvoir monter uniquement le dossier au lancement du service, sans impact pour la VM en dessous.

On va donc déclarer chaque volume dans les stacks avec les options de montage directement. Parmi les contraintes à relever :

Là où j’ai galéré, c’est pour ce connard de NAS. En effet, vous avez vu, je monte /Docker depuis ce NAS, mais pour une raison que j’ignore, /Docker/registry ne fonctionne pas, alors qu’il est bien présent. Et pourtant j’en fait des palanquées des montages NFS comme ça, à cibler un sous-dossier, sur plusieurs environnements, Debian, CentOS, mix des deux, même de l’EFS AWS, c’est dire. Et ça, que je teste en v3 ou v4.

Il aura fallu plusieurs essais ratés, des recherches frustrantes, une investigation en SSH directement sur le NAS, pour finir par demander un point de vue extérieur sur le forum NXI, pour avoir la solution, une solution qui me convient dans la mesure où elle fonctionne mais pas dans la logique qu’on doit appliquer. En effet, pour accéder aux sous-dossiers directement via NFS, c’est /volume1/Docker qui doit service de base, et pas /Docker. Me demandez pas pourquoi, oui c’est /volume1/Docker qui est déclaré dans le fichier /etc/exports sur le NAS, mais j’ai toujours pas compris pourquoi monter /Docker fonctionne quand même.

Enfin bon, voici donc la même stack, adaptée avec des volumes NFS bien déclarés :

version: "3.2"

volumes:
  smokedata:
    driver_opts:
      type: nfs
      o: "addr=192.168.1.200,rw,nfsvers=3,nolock,soft,exec"
      device: ":/volume1/Docker/smokeping/data"
  smokeconfig:
    driver_opts:
      type: nfs
      o: "addr=192.168.1.200,rw,nfsvers=3,nolock,soft,exec"
      device: ":/volume1/Docker/smokeping/config"

networks:
  smokeping:
    driver: overlay

services:
  smokeping:
    image: linuxserver/smokeping:191068eb-ls64
    networks:
      - "smokeping"
    ports:
      - "20080:80"
    environment:
      - "PUID=1001"
      - "GUID=1001"
      - "TZ=Europe/Paris"
    volumes:
      - type: volume
        source: smokedata
        target: /data
        volume:
          nocopy: true
      - type: volume
        source: smokeconfig
        target: /config
        volume:
          nocopy: true
    deploy:
      replicas: 1
      restart_policy:
        condition: any

Quand Swarm lance un déploiement, il va créer un volume local sur le nœud sélectionné, dont le détail aura cette forme (via docker inspect) :

[
    {
        "CreatedAt": "2019-12-08T19:48:43+01:00",
        "Driver": "local",
        "Labels": {
            "com.docker.stack.namespace": "smokeping"
        },
        "Mountpoint": "/var/lib/docker/volumes/smokeping_smokeconfig/_data",
        "Name": "smokeping_smokeconfig",
        "Options": {
            "device": ":/volume1/Docker/smokeping/config",
            "o": "addr=ip_nas,rw,nfsvers=3,nolock,soft,exec",
            "type": "nfs"
        },
        "Scope": "local"
    }
]

On retrouve bien nos éléments, et Docker gère le volume dans son arborescence comme un grand. On s’en occupe plus nous-même, c’est un peu mieux question erreurs possibles.

Road to Kubernetes

En soi, et depuis que j’ai l’onduleur, je n’ai plus de problèmes majeur avec le NFS, à part que sur un des nœuds, quand la VM redémarre, le montage NFS ne se fait pas (ses voisines avec strictement la même configuration n’ont pas ce problème). Du coup, il ne démarre dessus que les containers qui n’ont pas besoin de volume. Ça déséquilibre un peu la conso de RAM entre les VMs, mais c’est pas la mort.

L’objectif réel de tout ça est de pouvoir mettre à la retraite Docker Swarm pour jouer avec Kubernetes, via le projet K3S de Rancher qui est parfait pour les petites ressources de mon serveur (pour rappel on peu s’en servir sur un Raspberry Pi 3 ou 4). Je ne me voyais pas faire le sale à utiliser des volumes en host-path pour celui-ci, et pour exploiter déjà la solution NFS sur Azure parce que leurs outils de volumes sont à chier, ça marche très bien. En plus, avec cette syntaxe, je vais pouvoir tester d’utiliser Kompose pour faire le feignant et éviter d’écrire tous les manifestes à la main 🙂

Des alternatives au NFS ?

Si tant est que l’espace disque n’est pas une contrainte réelle sur les VMs (le SSD sous-jacent est pas non plus extensible à l’infini), il est possible d’utiliser d’autres solutions. Par exemple, l’homme qui a changé ma vie a publié un article sur Rook, qui se base sur une autre techno de stockage distribué, Ceph. Je suis tombé aussi sur Longhorn, un projet de stockage distribué au sein du cluster qui permet ensuite d’exporter sur un autre type de stockage. C’est encore un peu jeune, mais ça passera peut-être en test.

Une solution qu’a tenté aussi de me faire tester Nicolas Simond, c’est iSCSI. On sent le mec un peu trop habitué à VMWare 😀 Ceci dit, la techno est supportée sur Docker et Kubernetes donc vous pourriez éventuellement pouvoir l’exploiter en fonction de votre environnement. En parlant de VMware, j’ai vu un client nous demander si on pouvait supporter vSphere Storage for Docker, une extension pour gérer des volumes Docker sur les datastores VMware.

Tout ça pour dire que les options ne manquent pas pour vous adapter à votre environnement. Sur ce, j’ai mes autres stacks à refaire, je vous laisse 😉

Windows, WSL et Docker, mode d’emploi

lundi 25 novembre 2019 à 18:30

Soit Qwant n’est pas encore assez doué, soit je n’ai pas trouvé l’intégralité des infos que je cherchais sur ce sujet. Et après avoir vu la vidéo de Thomas, dans laquelle il manque un ou deux morceaux, comme je suis moi-même en train de tester Ubuntu via le Windows Subsystem for Linux, me suis dit qu’il fallait tester moi-même, et vous faire un retour. Et ça n’a pas été forcément tranquille.

Une solution qui a quelques prérequis pénibles

Docker for Windows a un fonctionnement tout de même bien différent de sous Linux. Sous ce dernier, il fait encore appel partiellement à LXC, qui permet de « conteneuriser » l’application à l’exécution. Sous Windows, choix a été fait de reposer sur Hyper-V, la couche de virtualisation de Windows. Hors, cette couche nécessite une version « Pro » au minimum de Windows, donc exit tous les Windows vendus avec les laptops grand public du marché. Pour ma part, j’utilise une version entreprise LTSC, vous savez pourquoi, donc c’est bon.

Le deuxième prérequis apparent est là encore une décision détestable : demander de créer/disposer d’un compte sur le Docker Hub pour pouvoir récupérer Docker Desktop for Windows. Alors même que la version Linux et Mac n’en demandent pas autant. Devoir filer une fois de plus des infos persos, à une boite américaine de surcroit, pour un truc opensource et gratuit, non merci. Fort heureusement, j’ai fini sur un article anglais par trouver le lien direct vers l’installeur, qui fonctionne parfaitement, comme quoi demander un compte alors qu’on verrouille pas le direct download est juste de la malhonnêteté. Ce qui est « drôle », c’est que l’article en question conseille tout de même la création du compte, arguant que ça permet le téléchargement d’images. Se peut-il que le rédacteur se soit planté en utilisant « download » plutôt que « upload », à savoir téléversement, c’est à dire déposer des images sur le Hub, qui là oui demande un compte ? Mais la plupart des images sont publiques sur le Hub, donc pas besoin de compte pour les télécharger.

Enfin bon, c’était entre autres le gros point qui manquait dans la vidéo de Thomas, le reste, ça ne va être grosso modo que de la transcription. J’ai le temps d’écrire, le téléchargement prend 1Go pratiquement…

Configuration de Docker for Windows

A l’installation l’utilitaire propose de cocher une case « Use Windows containers instead of Linux containers », que j’ai laissé décoché évidemment. Il faudra se délogguer de votre session à la fin de l’installation, un peu comme sous Linux ou il faut relancer la session pour prendre en compte l’ajout de votre utilisateur au groupe docker pour que le démon accepte que vous l’utilisiez.

Le démarrage et le redémarrage du service Docker sont longs, très longs comparé à Linux, je soupçonne qu’en fait en dessous c’est une machine virtuelle Hyper-V qui est démarrée/redémarrée, et c’est pas rapide (ça expliquerait aussi la taille du téléchargement ceci dit). Je dis ça parce qu’une des premières choses à faire est d’aller dans les options de Docker (clic droit sur la baleine dans la barre des tâches, puis « Settings »), Pour décocher la télémétrie (Usage statistics, encore cette saloperie), et cocher « Expose daemon on tcp://… without TLS », c’est lui le plus important en fait.

Une fois validé, il vous demandera certainement de redémarrer, faites donc et patientez de longues secondes…

Configuration du client Docker dans WSL

L’installation du client docker (et uniquement lui) est gérable de manière tout à fait classique via la documentation officielle, à savoir ajout de la clé GPG, ajout du dépôt, et installation du client. Faut-il vraiment remettre les commandes ? Allez :

$ sudo apt install apt-transport-https ca-certificates gnupg-agent software-properties-common curl
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
$ sudo apt install docker-ce-cli

Il faut ensuite paramétrer l’environnement pour indiquer au client docker de taper sur le démon Windows qu’on a exposé un peu plus tôt. Pour ça, direction le fichier ~/.bashrc ( je préfère utiliser ~/.bash_aliases qui permet d’être plus indépendant de la distribution, et le bashrc d’Ubuntu est configuré pour charger celui-ci s’il existe), et ajouter une ligne dedans :

export DOCKER_HOST=tcp://localhost:2375

On le recharge ( source ~/.bashrc ) et roulez jeunesse. Un petit docker info devrait vous rassurer :

$ docker info
Client:
 Debug Mode: false

Server:
(...)
Kernel Version: 4.9.184-linuxkit
Operating System: Docker Desktop
(...)

Mes soupçons se confirment, c’est bien une machine virtuelle Linux qui est utilisée avec un noyal 4.9.x comme référence pour le démon Docker.

Reconfiguration WSL pour les volumes

Ah, oui, en l’état ça fonctionne, vous pouvez démarrer du container à foison, mais pour la gestion des volumes c’est pas encore tout à fait ça. En effet, par défaut sur WSL les volumes de Windows sont « montés » dans le dossier /mnt/c, /mnt/d, etc. Et ceux-ci ne sont pas utilisables avec Docker, on va voir pourquoi :/

Il faut pour ça commencer par reconfigurer WSL, via un fichier de configuration /etc/wsl.conf avec le contenu suivant :

[automount]
enabled = true

options = "metadata,umask=22,fmask=11"
mountFsTab = false
root = "/"

En fait, le « root », quand il n’est pas renseigné c’est /mnt. Vous commencez à voir où on va ?

Fermez la session, parce qu’il faut qu’on redémarre ensuite le service « LXSSManager », c’est le service système qui se charge de l’environnement WSL (oui, cherchez pas la logique du nom). Pour ça, j’ai une habitude fâcheuse mais très rapide depuis plusieurs années, c’est le raccourci clavier Win+R, services.msc :

Quand on relance, les volumes C:\, D:\ etc… ne sont plus montés dans /mnt/c/… mais directement dans /c/…, et ça tombe bien, puisque c’est le même point de montage dans la machine virtuelle de Docker Desktop. Il aura donc les bonnes informations pour aller créer/récupérer ses volumes. Attention, ça veut donc dire qu’il faut placer ses volumes persistants non pas dans la session WSL mais bien dans l’arborescence Windows. Avec toutes les limitations que posent le système de fichiers NTFS (sur la casse, les permissions…) 🙁

Y’a pas à dire, Linux c’est quand même mieux (ou le WSL 2 ?)

Ça a été long, chiant, mais ça fonctionne parfaitement. Malgré tout, c’est un sacré bidouillage, et une consommation de ressources sans commune mesure avec un démon Docker linux natif. C’est pas pour rien non plus que je me suis débarrassé de Windows au boulot, avec toutes les contraintes que ça m’a apporté derrière.

Microsoft l’a bien compris, et les améliorations tirées de ses enseignements sur Azure notamment l’ont poussé à travailler sur un WSL 2.0 qui embarquera un vrai noyau Linux pour pouvoir cette-fois-ci prendre en charge la version Linux de docker de manière native, donc beaucoup plus léger qu’un système à base de VM Hyper-V. Oui parce que j’ai pas évoqué l’impact sur les performances, mais disons simplement que c’est bien pour construire ses applis et tester leur stabilité, mais c’est pas l’environnement rêvé pour valider les performances…

WSL a d’autres limitations via certains programmes qu’on pourrait aborder dans d’autres articles. Déjà celle de Docker est contournée 🙂

Réduire la taille d’un disque virtuel au format VDI

dimanche 17 novembre 2019 à 10:30

Après mon changement d’OS sur le PC du boulot, j’avais notamment transféré la machine virtuelle Linux que j’utilisais pour récupérer notamment l’environnement SSH, Git, et Bash de manière générale. Et en regardant l’espace utilisé sur le système hôte, j’y ai vu un gros souci : la taille du disque virtuel. J’ai donc cherché à corriger ça.

L’image approchait les 40Go :

$ ll
total 75949920
drwxr-xr-x 4 seboss666 seboss666 4096 04.10.2019 09:25 ./
drwxr-xr-x 3 seboss666 seboss666 4096 04.10.2019 08:54 ../
drwxr-xr-x 2 seboss666 seboss666 4096 04.10.2019 08:54 Logs/
drwxr-xr-x 2 seboss666 seboss666 4096 05.06.2019 09:25 Snapshots/
-rw------- 1 seboss666 seboss666 8603 04.10.2019 09:25 SebLBNvm.vbox
-rw------- 1 seboss666 seboss666 8603 04.10.2019 09:06 SebLBNvm.vbox-prev
-rwxrwxrwx 1 seboss666 seboss666 40155217920 04.10.2019 09:06 SebLBNvm.vdi*

Pourtant, une fois dans la VM, la consommation n’est pas si importante :

$ df -h /
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/mapper/lubuntu--vg-root 38G 7,3G 29G 21% /

L’explication est simple, le disque virtuel a beau être alloué de manière dynamique, par le passé j’ai pratiquement rempli cet espace, et le fichier ne se réduit pas de lui-même une fois le ménage effectué. C’est un fait bien connu des administrateurs de bases de données qui doivent exécuter des tâches de maintenance pour éviter que les tables explosent.

Pour réduire la taille, mes premières recherches m’ont conduit à une procédure qui demande de passer par deux étapes de conversion, VDI->VMDK, puis VMDK->VDI. On commence par faire la première passe, de VDI à VMDK. Alors avant de vous montrer la commande, il faut passer par une commande supplémentaire, zerofree, qui permet de réécrire des zéros sur l’espace libre, parce que sinon :

$ vboxmanage clonehd --format vmdk SebLBNvm.vdi SebLBNvm.vmdk
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone medium created in format 'vmdk'. UUID: 17f3ff3e-d23d-4091-a68d-00e9173de795

Voyons le résultat :

$ ll
total 75949920
drwxr-xr-x 4 seboss666 seboss666 4096 04.10.2019 09:25 ./
drwxr-xr-x 3 seboss666 seboss666 4096 04.10.2019 08:54 ../
drwxr-xr-x 2 seboss666 seboss666 4096 04.10.2019 08:54 Logs/
drwxr-xr-x 2 seboss666 seboss666 4096 05.06.2019 09:25 Snapshots/
-rw------- 1 seboss666 seboss666 8603 04.10.2019 09:25 SebLBNvm.vbox
-rw------- 1 seboss666 seboss666 8603 04.10.2019 09:06 SebLBNvm.vbox-prev
-rwxrwxrwx 1 seboss666 seboss666 40155217920 04.10.2019 09:06 SebLBNvm.vdi*
-rw------- 1 seboss666 seboss666 37617532928 04.10.2019 09:25 SebLBNvm.vmdk

Comme on le voit, le résultat n’est pas très efficace. zerofree est un utilitaire qui s’exécute en mode rescue ou via un live cd/usb, et demande paradoxalement de remonter en read-only le volume concerné.

En cherchant un peu plus à propos de zerofree et des réductions d’image disque, je suis tombé sur le Saint Graal, spécifique au format VDI, la commande vboxmanage dispose d’une option « compact » qui fait exactement le boulot sans se taper la double conversion. Un gain de temps appréciable, et un résultat intéressant :

$ vboxmanage modifymedium disk "./SebLBNvm.vdi" --compact
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
$ l
total 50365484
drwxr-xr-x 2 seboss666 seboss666 4096 04.10.2019 09:53 Logs/
drwxr-xr-x 2 seboss666 seboss666 4096 05.06.2019 09:25 Snapshots/
-rw------- 1 seboss666 seboss666 8603 04.10.2019 10:29 SebLBNvm.vbox
-rw------- 1 seboss666 seboss666 8603 04.10.2019 09:25 SebLBNvm.vbox-prev
-rwxrwxrwx 1 seboss666 seboss666 11418992640 04.10.2019 10:59 SebLBNvm.vdi*

Ah ben c’est mieux. Alors évidemment, pour m’assurer que c’est peinard j’ai fait un backup du fichier avant, et je ne peux que recommander de faire cette sauvegarde au préalable.

Les formats de disques virtuels, tout un monde

Je pourrais presque faire un article complet sur les principaux formats de disque virtuel, de leurs avantages et inconvénients, les implications sur la consommation, les performances, et l’aspect ouvert ou non des formats. Mais bon, déjà là vous avez une petite bidouille si vous êtes dans une chasse à l’espace disque et que vous travaillez avec des machines virtuelles. Ici, le format était celui de Virtualbox, et donc j’ai utilisé les outils fournis avec, mais vous pouvez sinon vous tourner vers l’utilitaire qemu-img que j’avais évoqué il y a cinq ans (déjà !).