Veeam Software Appliance – Remote kickstart ! Partie 3

Industrialiser le Déploiement avec Packer

Bienvenue dans la troisième partie de notre aventure d’automatisation ! Si vous avez suivi les deux premiers épisodes, vous connaissez maintenant la théorie et vous avez mis les mains dans le cambouis avec notre script auto-deploy. Aujourd’hui, nous allons vraiment faire passer les choses à un autre niveau : l’industrialisation du déploiement avec Packer.

L’objectif ? Déployer plusieurs appliances en même temps – une Veeam Software Appliance, un proxy, et un repository – le tout avec une seule commande. C’est là où ça devient vraiment intéressant !

Qu’est-ce que Packer et pourquoi c’est magique

Pour ceux qui ne connaissent pas Packer, il s’agit d’un produit HASHICorp qui vous permet de faire du déploiement automatique de machines. Ce qui me plaît vraiment, c’est sa polyvalence – il fonctionne dans de nombreux environnements différents.

Vous pouvez l’utiliser pour automatiser Docker, AWS, Hyper-V, VMware, et bien d’autres. Personnellement, j’ai utilisé Packer sur VMware Workstation parce que c’est là que j’avais le plus de possibilités. Mais rassurez-vous, le concept reste le même peu importe votre infrastructure.

Préparer vos fichiers de configuration

La première étape, c’est de revenir à nos fichiers de configuration – ceux que nous avons créés avec notre tool auto-deploy.

Voici ce que j’ai fait :

J’ai créé un fichier de configuration pour la VSA, basé sur la dernière ISO. Pour cette configuration, l’important c’est de mettre « config file only » à true – cela signifie que nous n’allons pas modifier l’ISO, nous allons seulement générer un fichier kickstart. Le reste est configuré par défaut : DHCP activé, tous les composants tiers désactivés.

Ensuite, j’ai créé un fichier pour le proxy. Cette fois, j’utilise l’Infrastructure Appliance comme ISO de base. Même approche : config file only à true, tout en DHCP, et je désactive node exporter et debug pour avoir un proxy vraiment basique.

Enfin, j’ai configuré le Hardened Repository – toujours avec l’Infrastructure Appliance comme base, mais cette fois en tant que VHR. Configuration minimaliste, DHCP, point barre.

Une fois ces trois fichiers prêts, je les ai passés à mon outil auto-deploy. L’outil a validé chaque configuration et généré les kickstart correspondants.

Configurez Packer pour VMware

Maintenant, le cœur du processus. J’ai créé un fichier de configuration Packer appelé vsa-via-vmware.json.

Voici ce qu’il fait :

Il télécharge l’ISO de la Veeam Software Appliance – j’ai profité de cette étape pour mettre à jour vers la dernière version. Il démarre la machine avec cette ISO et crée une machine Red Hat, version 22, en BIOS UEFI avec un CD-ROM en SATA.

Il alloue 8 CPU et 16 GB de RAM – c’est important pour que tout fonctionne correctement. Il crée même deux disques, ce qui est vraiment important parce que c’est nécessaire pour valider que la VSA tourne bien.

Mais ce qui est vraiment intéressant, c’est le paramètre boot command. C’est là que la magie opère. Packer simule des actions au clavier pour automatiser complètement le processus de boot.

La Magie du Boot Command

Le boot command, c’est un peu comme un macro qui va appuyer sur les touches à votre place. Voici ce qu’il fait :

Il attend quelques secondes, puis il appuie sur Entrée. Ensuite, il appuie sur « e » pour éditer la séquence de démarrage. Après ça, il commence à supprimer l’intégralité de la séquence de boot originale avec des delete, delete, delete…

Une fois qu’il a terminé, il réécrit les fichiers de configuration avec les paramètres corrects. C’est exactement ce que nous voulions faire, mais automatisé. Pas besoin de cliquer, Packer le fait pour vous.

Ajustements Nécessaires aux Fichiers GRUB

Maintenant, il y a une petite nuance importante. Chaque appliance a ses propres paramètres, et notamment un label GRUB différent.

Pour la VSA, le label est « Veeamsa ». Pour le proxy et le repository, ce peut être différent. J’ai dû récupérer les fichiers GRUB générés pour chaque kickstart et corriger les labels dans mon fichier Packer correspondant.

Pas de panique, c’est une opération une seule fois. Une fois que c’est fait, vous pouvez le réutiliser autant que vous voulez.

Lancer Packer et Voir la Magie

Et maintenant, le moment de vérité. Je vais ouvrir VMware d’un côté et une invite de commande de l’autre, et je tape :

./packer.exe build -parallel-builds=3 vsa-via-vmware.json

J’ai demandé à Packer de construire trois machines en parallèle pour aller plus vite. Vous pouvez aussi les faire séquentiellement si vous préférez.

Et c’est là que c’est cool : sans aucun effet de démo, Packer crée les trois machines. J’ai pu voir sur l’écran que :

Packer lance un serveur HTTP pour chaque machine (c’est pour servir les fichiers kickstart). Il attend 5 secondes, puis commence à entrer les commandes. Les trois machines se lancent et commencent leur processus de configuration sans intervention manuelle.

Et vous savez quoi ? Aucune question n’est posée. Aucun assistant de configuration. Packer réécrit simplement tout avec le kickstart approprié et les trois machines se configurent automatiquement.

Les Avantages du Kickstart à Distance

Ce qui est vraiment puissant ici, c’est que nous n’avons pas modifié l’ISO. L’ISO de base reste la même. Ce que nous faisons, c’est simplement fournir un kickstart différent à chaque fois, servi via HTTP.

C’est un concept que vous trouverez dans Red Hat, mais l’avoir implémenté avec Packer et Workstation c’est vraiment cool. C’est du vrai déploiement à distance, et c’est reproductible à 100%.

Et Après ?

Vous vous demandez peut-être : « Et après qu’elles soient déployées ? »

C’est une excellente question ! Dans la partie 4 (qui arrive bientôt), je vous montrerai comment interconnecter automatiquement ces trois machines ensemble via un script PowerShell. Imaginez : vous lancez Packer, les trois machines se déploient, puis un script se charge de les configurer pour qu’elles communiquent entre elles.

Ce script ajoutera les licences, le repository, le proxy – le tout automatiquement. Et nous explorerons les nouveaux paramètres optionnels du kickstart pour encore plus d’autonomie. Nous verrons même comment ajouter des fournisseurs de services et d’autres configurations avancées.

Une Petite Note sur les Limitations

Avant de terminer, je dois vous dire : j’ai tenté Packer sur Hyper-V et ça n’a pas fonctionné aussi bien. Le module Hyper-V de Packer ne savait pas comment ajouter un deuxième disque – c’est frustrant. Donc j’ai dû travailler avec des machines pré-configurées et utiliser un script PowerShell pour changer les disques et l’ordre de boot.

Mais sur VMware, c’est du pur bonheur. Et même sur vSphere, vous devriez avoir de bonnes possibilités.

Conclusion : Merci à la VSA

Ce qui rend tout cela possible, c’est vraiment l’ISO de la Veeam Software Appliance qui permet toute cette automatisation. C’est impressionnant d’avoir une appliance aussi flexible.

Nous avons maintenant les outils pour industrialiser complètement le déploiement de nos appliances Veeam. Plus besoin de cliquer dans des assistants. Plus besoin de configuration manuelle répétitive.

Si vous avez des questions ou si vous trouvez d’autres cas d’usage intéressants, n’hésitez pas à les partager en commentaire. Et bien sûr, restez connectés pour la partie 4 – c’est là que nous monterons vraiment en puissance !

Merci beaucoup de m’avoir suivi, et à bientôt ! 😊