Veeam Software Appliance – Autodeploy script : appropriez le vous – Part 5

Bonjour ! Après avoir passé les 4 premières vidéos à construire les bases du script Autodeploy pour Veeam Software Appliance, nous en arrivons enfin à la partie que j’attendais : les fonctionnalités optionnelles. C’est ici que la magie opère vraiment, et c’est aussi ici que vous allez pouvoir vraiment customiser votre déploiement selon vos besoins.

Les Fonctionnalités Optionnelles du Script

Le script Autodeploy offre plusieurs possibilités fantastiques pour enrichir votre déploiement. Je vais vous les présenter une par une, en détail, car chacune a ses petites subtilités.

Ajouter une Licence VBR – C’est la plus simple à mettre en place. Vous pouvez directement intégrer votre fichier de licence lors de la création de l’ISO. Le script va se charger de le copier au bon endroit et de l’installer automatiquement au premier démarrage.

Node Exporter – Celui-ci est un peu particulier. Je dois vous être honnête : ce n’est pas encore officiellement supporté par Veeam. Si vous ouvrez un ticket de support et que Node Exporter pose problème, vous risquez d’essuyer un refus. Cependant, ça viendra, j’en suis convaincu. N’hésitez pas à faire remonter vos demandes sur le forum R&D si vous en avez besoin.

Ajouter un Service Provider – Voilà qui est puissant ! Si vous déployez votre VSA en production directement, le script peut ajouter le tenant, les identifiants et l’IP du Cloud Connect pour connecter votre appliance à la Service Provider Console, tout cela en kickstart. C’est vraiment pratique.

Configuration Restore – Et bien, c’est la partie la plus complexe du script. Imaginez : vous aviez une VBR en production, vous avez exporté votre fichier de configuration, et maintenant vous voulez le restaurer automatiquement sur une nouvelle VSA vierge. Normalement, vous devriez passer par l’interface graphique, le Host Manager, cliquer sur restaurer, etc. Avec le script, tout se fait automatiquement dès le premier démarrage.

Comment Fonctionne le Script en Détail

Je dois vous avouer quelque chose : ce script est complexe, mais repose sur des workflows qui s’adaptent selon le type d’appliance (VSA, VIA, VAIVmware, VHR).

Quand vous lancez le script PowerShell, voici ce qui se passe :

Il charge votre fichier de configuration JSON, il vérifie que toutes les prérequis sont en place, il teste les fonctionnalités, puis il s’engage dans un workflow précis selon votre type d’appliance. C’est dans ce workflow que toute la magie s’opère.

La Complexité Cachée : PowerShell pour Linux

Vous voulez connaître la partie la plus horrible du script ? C’est quelque chose dont je ne suis pas particulièrement fier, mais c’était nécessaire : du code PowerShell qui génère du Bash.

Oui, vous avez bien lu. Le script PowerShell crée des fichiers de configuration (des fichiers .cfg) qui seront lus par un système d’exploitation Linux, qui vont générer des scripts Bash. C’est une sorte d’emboîtement de langages. Vous voyez ces petits symboles avant certains paramètres ? Ils sont là pour indiquer que c’est PowerShell qui doit les traiter, pas Bash qui les interprétera plus tard.

Franchement, je ne vous conseille pas de mettre les mains dedans si vous ne savez pas ce que vous faites. Et si vous rencontrez des problèmes, il y a 99 % de chances que ce soit à cause d’une confusion entre ce qui est du PowerShell pré-déploiement et ce qui est du Bash post-déploiement.

Installation de Node Exporter Hors Ligne

Puisque nous partons du principe que votre VSA n’aura probablement pas accès à Internet, Node Exporter se doit d’être installé complètement hors ligne. Le script utilise donc un dossier de dépendances offline trouvable sur GitHub, qui contient tous les packages RPM nécessaires.

Voici le processus :

D’abord, le script copie le dossier offline repo dans l’ISO. Ensuite, il ajoute les règles firewall pour ouvrir le port 9100 (celui utilisé par Node Exporter). Puis, au premier démarrage, il crée un référentiel YUM temporaire pointant vers ce dossier offline, installe Node Exporter, nettoie les fichiers temporaires, et configure le service. C’est zéro dépendance externe.

La Restauration de Configuration : Le Défi Ultime

Concentrez-vous bien, car c’est la partie la plus technique : la restauration de configuration nécessite trois fichiers distincts :

Un fichier BCO (le backup de configuration crypté), un fichier XML pour piloter la restauration, et un script Bash qui communique en HTTP avec le Host Manager. Et là, il y a quelque chose d’important à comprendre : si vous avez un Security Officer activé, votre configuration est doublement cryptée.

La première couche de cryptage est appliquée lors de l’export de la configuration depuis la console VBR (c’est normal). Mais la deuxième couche vient du Security Officer lui-même. Donc quand vous restaurez, le script doit se connecter au Security Officer, obtenir le bon mot de passe de déchiffrement, puis envoyer la commande de restauration avec le fichier XML.

Le fichier XML est assez simple : il contient simplement une référence hardcodée au fichier BCO et le mot de passe pour le déchiffrer. C’est à vous de modifier ce fichier XML avec vos propres données avant de lancer le script.

Et oui, vous aurez besoin du dossier offline repo aussi, car le processus nécessite que plusieurs dépendances soient disponibles.

Workflows Différents pour Chaque Type d’Appliance

J’ai créé des workflows distincts pour VSA et pour les autres appliances (comme VIA) parce que chacune a ses petites spécificités. Par exemple, sur l’Appliance d’Infrastructure Veeam (VIA), il y avait un bug dans le code par défaut concernant le token de déploiement. J’ai donc dû ajouter une correction spécifique dans le kickstart.

Mais globalement, la structure reste la même : modification du GRUB, modification du kickstart, gestion des configurations optionnelles, et selon le type, application des workflows spécialisés.

Caractères Spéciaux et Encodage UTF-8

Une dernière chose importante : parce que ce script tourne sur Windows mais génère du code pour Linux, nous devons gérer très attentivement l’encodage. C’est pourquoi PowerShell 7 est obligatoire. Les versions précédentes ne gèrent pas correctement l’encodage UTF-8 en ligne de commande.

Voilà, C’est Fini !

Nous avons traversé ensemble ces 5 vidéos, et nous avons plongé très profondément dans le fonctionnement du script Autodeploy. Je le reconnais, c’est complexe, c’est dense, et par moments c’est même un peu chaotique dans l’imbrication des technologies. Mais maintenant vous comprenez vraiment comment tout fonctionne.

Mon souhait, c’est que vous puissiez maintenant adapter ce script à vos besoins spécifiques. Et si vous avez des questions, je suis là dans les commentaires. N’hésitez pas, c’est pour ça que je suis là.

Merci de m’avoir suivi jusqu’au bout, et bonne chance avec vos déploiements Veeam automatisés !

Ciao !