PROJET AUTOBLOG


Le blog de Seboss666

Site original : Le blog de Seboss666

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Debian, VMware, Terraform sont dans un bateau…

lundi 2 mars 2020 à 18:30

J’ai eu récemment à déployer une vingtaine de machines sur un cluster Private Cloud Vmware fourni par OVH. J’ai pour ça testé le code qu’un de leurs ingénieurs a partagé sur le blog d’OVH, mais ça ne s’est pas déroulé comme prévu. Et la solution a pris du temps, et c’est dégueulasse…

Un vrai parcours du combattant

Mes machines doivent être déployées en Debian 9 (on pleure pas trop vite s’il vous plait), pas le choix parce qu’il nous manque encore des prérequis internes pour la bonne gestion de Debian 10 chez nous. Qui dit déploiement par terraform dit d’abord création d’un template Debian 9.

Au passage je vous recommande vivement de vous intéresser à Terraform si vous comptez bosser de l’infrastructure « cloud », y’a une quantité hallucinante de providers et c’est vraiment un outil sympa à utiliser, qui s’intègre assez facilement dans un flux de déploiement automatisé de bout en bout.

Au début mon manager m’a filé un dépôt avec une configuration Packer, autre outil développé par Hashicorp, qu’il avait utilisé pour du CentOS 7. Après avoir passé une après-midi à essayer de comprendre comment fonctionne le preseed de l’installateur Debian, et échoué à le faire utiliser avec Packer (au passage, si on compare preseed à kickstart, preseed c’est de la merde en barre), j’ai décidé de créer mon template à la main à partir de l’iso officielle 64bit, avec installation d’open-vm-tools, comme recommandé par la documentation de VMware.

Puis, une fois le template prêt et rangé dans son dossier, je prépare le code rapidement et procède à une première tentative de création d’une machine virtuelle à partir du template. Comme on l’imagine, puisqu’on en parle aujourd’hui, ça ne s’est pas vraiment déroulé comme je l’attendais :

Error: error sending customization spec: Customization of the guest operating system 'debian9_64Guest' is not supported in this configuration. Microsoft Vista (TM) and Linux guests with Logical Volume Manager are supported only for recent ESX host and VMware Tools versions. Refer to vCenter documentation for supported configurations.

Et il supprime la machine virtuelle. Arf. Il se trouve que j’ai le même message après une tentative manuelle depuis l’interface web en cochant l’option qui correspond à la personnalisation de l’OS. Damned. Déjà, le message est sympathique car il parle de Vista, cancer nécessaire de Microsoft qui aura quand même permis à terme d’avoir le génial Windows 7 (qui vient de prendre sa retraite), mais aussi et plus surprenant, de LVM. Surprenant car je sais que VMware supporte parfaitement LVM dans ses différents outils, pour avoir bouffé du VMware Converter sur un projet précédent. Sans plus de conviction, je perds donc du temps à recréer un second template partitionné sans LVM cette fois; même punition, même message, l’erreur est donc générique et débile.

Je me tourne alors vers le support OVH, en leur donnant tous les détails de mes manipulations et tests. Leur réponse, en substance :

On reproduit, mais on comprend pas non plus

Et en effet, en cherchant partout sur les docs VMware ça devrait pas bloquer. Mais des réponses comme celle-ci ne m’avancent pas à grand chose.

Il fallait que j’avance donc j’ai déployé mes machines de pré-production à la main, fourni les accès à l’agence de développement et j’ai un peu laissé de côté, pendant que je relançais à intervalle régulier le support pour avoir des nouvelles.

Réponse quelques dizaines de jours et partage de traces terraform & co plus tard : il faut modifier le type de machine virtuelle qu’on crée à Ubuntu, même si on installe Debian dedans. Mentir à l’hyperviseur, bravo, il est vrai que je l’avais vu passer dans mes recherches Google, mais ça ne me plaît pas vraiment et donc, j’ai pas testé. Mais maintenant et au point où on en est, pourquoi pas. Le support me dit que je peux tester avec leur template, mais ça échoue sur la même erreur, bravo.

J’entreprends donc de refaire un nouveau template, en mentant, avec LVM, et je réinstalle les mêmes packages. Nouvelle tentative de déploiement : ça semble fonctionner, je n’ai plus le message d’erreur de personnalisation, mais pas de bol, ça échoue une étape plus tard. Ce coup-ci cependant, Terraform me laisse la machine pour débug, et affiche ce message :

An error occurred while customizing VM client-test1-preprod1. For details reference the log file <no_log> in the guest OS.

j’ai vraiment pas de bol, il devrait y avoir un fichier de log, il n’existe pas. Je découvre malgré tout un truc bizarre : la machine virtuelle est bien démarrée, mais la carte réseau n’est pas connectée, alors que la case est bien cochée dans le template. Je refouille sur Google, et là, je tombe sur un message récent, qui n’existait pas au début de mon problème, qui parle d’un souci avec l’unit systemd d’open-vm-tools.

Je retourne donc dans le template (qu’on convertit en machine virtuelle pour pouvoir en modifier le contenu), et plutôt que de modifier le fichier original qui pourrait être écrasé par une éventuelle mise à jour, j’exploite les capacités d’override de systemd dont vient de parler Cascador sur le Blog Libre :

$ export EDITOR=vim
$ sudo systemctl edit open-vm-tools.service
#Contenu de l'override
[Unit]
After=dbus.service

On repasse en template, et on relance terraform, et là, 1m30s après :

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Et tout ça, ça a pratiquement pris encore une après-midi qui n’a pas pu être consacrée à d’autres sujets (dont une investigation sur une corruption fréquente de base RPM sur du Redhat 7 qui semble causée par une configuration qu’on déploie chez tous les clients…).

Comme d’habitude, je cherche et constate que personne n’a remonté le problème chez Debian. J’ai failli le faire, avant de comparer au paquet Debian 10, et je me suis ravisé, car de toute façon, Debian 9 n’a plus qu’un an et demi devant lui, et le nombre de projets qu’on sera amené à mener dans un environnement similaire fait qu’on pourra supporter cette petite bidouille. J’ai tout de même partagé au support OVH qui pourra, au besoin, transmettre aux futurs infortunés qui seraient contraints au même déploiement sans avoir lu cet article.

VMware, c’est de la merde ?

En vrai pas tant que ça, mais effectivement sur ce point, Debian et Ubuntu partageant une base commune, je ne comprend pas pourquoi il ne « supporterait » pas le fait de déclarer correctement qu’on utilise une Debian, surtout qu’il bosse parfaitement derrière : hostname, fichier interfaces, tout est là, proprement configuré. On rage d’autant plus du coup d’avoir perdus plusieurs après-midi et patienté plusieurs jours sur un truc aussi bête.

Et dans le dépôt d’open-vm-tools, il n’y a pas de fichier d’unit systemd, je pense donc que c’est une faiblesse introduite par le mainteneur du paquet pour Debian. D’ailleurs, quand on voit le nombre de différences entre celui pour Debian 9 et celui pour Debian 10, c’est qu’il a dû être plus longuement testé et donc les problèmes mieux identifiés. Donc là non plus on ne peut pas entièrement blâmer les développeurs, même si un petit coup de pouce documentaire n’aurait pas été de trop de la part de l’éditeur. On salue par contre sans problème le choix des licences rattachées au code publié, pas évident puisque VMware est un éditeur de logiciel majoritairement propriétaire à la base.

De mon côté, j’aimerai tester Terraform sur un autre hyperviseur, en l’occurrence Proxmox puisque je l’utilise chez moi et sur le serveur physique qui héberge entre autre ce blog, mais il n’y a pas de provider officiel, juste un provider indépendant qui semble du coup avoir ses propres contraintes qu’il faudra apprivoiser. Par contre vu le rythme actuel de publication, ça sera dans deux ans hein ^^’