Debian, VMware, Terraform sont dans un bateau…
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 :
1 |
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 :
1 |
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 :
1 2 3 4 5 |
$ 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 :
1 |
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 ^^’
C’est triste à dire, mais oui, sous Debian les preseed c’est pas clair du tout et pas pratique du tout avec Packer. C’est largement plus simple de faire une install avec debootstrap suivi par un petit coup de tasksel.
Bonjour, sur github on trouve pas mal d’exemple de configurations Packer pour Debian permettant de démarrer facilement. On construit des images (pour libvirt principalement et pour du cloud) depuis des années avec et globalement ça marche très bien.
Quant au preseed le plus simple est de partir de celui d’exemple fourni dans la doc de chaque release. Le plus difficile (casse-gueule) étant le partitionnement la syntaxe pour partman étant « fragile ».
J’ai testé avec succès terraform + packer + ansible …. qui eux aussi étaient déjà dans un bateau 🙂
https://www.carmelo.fr/devops-packer-terraform-et-ansible-sont-dans-un-bateau-la-demo/
Terraform avec vmware j’ai testé, mais de façon plus restreinte.
Pour ma part : le couple terraform et lxd est parfait … Et si en plus on ajoute packer pour avoir de l’image quasi prête on ne peut être qu’amour et paix 🙂
Bonjour, j’ai eu exactement les mêmes problématiques .
Comme tu l’as compris je message sur lvm est un message d’erreur générique .
J’ai complément laissé tomber car je ne trouvais également aucun sujet sur le problème .
Le seul moyen que j’ai trouvé c’est de passer par un script en powercli qui va échanger des paramètres avec le guest os au travers des vmware tools
J’ai le même problème avec Terraform/Proxmox. Je ne sais pas ce que vaut le projet cité, j’étais aussi tombé dessus, mais pas testé. J’ai aussi essayé avec salt-cloud, c’est pas vraiment mieux. Du coup, Je pense remplacer proxmox par OpenNebula progressivement, sans conviction (il y a quand même des trucs super bien faits dans proxmox (gestion ceph, etc…))…
Pour terraform, il faut effectivement que le Guest os version soit ubuntu64 pour que cela fonctionne (du mins pour Debian 10).
ça fonctionne, y compris pour le réseau. (inspiré de https://github.com/cloudmaniac/terraform-deploy-vmware-vm)
Par contre, effectivement, pour Packer, Debian+preseed, j’ai jamais réussi à passer le boot_command… j’avais abandonné et fait comme vous un template « à la main ».
Salut, Je suis tombé un peu par hasard sur ton site, super taff ! Pour info j’ai fait des templates Debian buster 10.4 dispo ici: – https://github.com/tsugliani/packer-vsphere-debian-appliances (Le tout est buildé via Packer) La petite difference c’est que je n’utilise pas la guest customization VMware mais les properties OVF pour configurer les VMs, c’est très pratique, et tu geres du coup le cycle de vie complet de tes templates comme tu le souhaite. Aussi prochainement Terraform va entierement supporter les property OVF, ce qui te permet de faire des trucs très interessants ! -> https://github.com/hashicorp/terraform-provider-vsphere/pull/1105 -> https://www.virtuallyghetto.com/2020/06/full-ova-ovf-property-support-coming-to-terraform-provider-for-vsphere.html Si ca peut… Lire la suite »
Ben c’est cool que ça arrive, j’en avais juste besoin y’a quatre mois par contre 😀 J’en toucherai deux mots aux collègues la semaine prochaine, j’en connais un en particulier qui sera content qu’on ait plus à mentir, parce qu’il est comme moi ça lui gratte dans les coins quand on doit faire ce genre de conneries pour faire marcher un truc. Après on ne déploie pas d’OVA, nos procédures créent directement le template sur le cluster où les VMs seront déployées (parfois même via du Gitlab-CI, même si on réserve encore ça pour des plateformes cloud type Azure/AWS/GCP pour… Lire la suite »
Pas de soucis, pour information rien ne t’empeches d’upload le template/OVA sur ton cluster final dans ta chaine CI/CD et ensuite après clone des VMs à partir de ce template utiliser les properties ovf ca marche également. (c’est ce que je fais)