Debian, VMware, Terraform sont dans un bateau…

closeCet article a été publié il y a 4 ans 26 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

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 :

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 :

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 :

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

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 ^^’

9 Commentaires
Le plus ancien
Le plus récent
Commentaires en ligne
Afficher tous les commentaires
Loïc
Loïc
02/03/2020 19:58

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.

eric
eric
03/03/2020 16:48

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 ».

Carmelo
03/03/2020 19:28

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 🙂

fares
fares
04/03/2020 07:18

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

Fritange
Fritange
18/03/2020 16:05

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…))…

Tuxi
Tuxi
23/03/2020 18:23

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 ».

tsugliani
tsugliani
15/06/2020 19:43

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 »

tsugliani
21/06/2020 20:58
Répondre à  Seboss666

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)