Autodeploy : quoi de neuf avec la version 13.1

Salut à toutes et à tous ! J’espère que vous avez passé un bel été et que la rentrée se déroule en douceur de votre côté. Chez moi, elle rime avec une actualité que j’attendais avec impatience : l’arrivée de Veeam Backup & Replication 13.1, et surtout les nouveautés qui l’accompagnent du côté de la Veeam Software Appliance.

Comme beaucoup d’entre vous le savent déjà, j’ai développé un gros script PowerShell pour industrialiser tout le processus de déploiement automatique de ces appliances, ce que j’appelle communément Autodeploy. Avec cette nouvelle version 13.1, pas mal de choses ont bougé, et j’avais envie de prendre le temps de vous expliquer tout ça tranquillement.

Autodeploy passe en version 2.8 : attention, breaking change !

Si vous cherchez le projet, il est disponible sur GitHub sous le nom Autodeploy : https://github.com/BaptisteTellier/autodeploy

La nouvelle mouture porte le numéro 2.8 et je préfère vous prévenir tout de suite : c’est un breaking change. Ce script fonctionne uniquement avec la version 13.1. Je n’ai volontairement pas cherché à assurer la rétrocompatibilité, tellement les changements sont nombreux. Alors soyez vigilants avant de mettre à jour.

Un script enfin cross-platform

Première grande nouveauté, et je tiens vraiment à remercier les contributeurs pour cette pull request : le script est désormais cross-platform. Concrètement, quand il détecte un environnement Linux ou macOS, il appelle directement l’outil de gestion des ISO natif. Fini l’obligation de passer par WSL ou de bidouiller des modifications à la main. Vous pouvez maintenant faire tourner Autodeploy à peu près n’importe où, et franchement, ça change la vie.

Dans la même contribution, on retrouve aussi l’utilisation du bon paramètre pour la partie XOR ISO. Au lieu d’être en mode « keep », on passe en mode « replay », ce qui permet également de faire fonctionner le tout depuis une clé USB. Un petit détail en apparence, mais très pratique au quotidien.

Quatre nouvelles clés JSON pour la VSA

Avec la 13.1, quatre nouvelles clés JSON font leur apparition dans le workflow de la Veeam Software Appliance. Elles sont toutes désactivées par défaut, et vous les retrouverez évidemment dans la documentation.

La première, External Manager, permet d’indiquer que l’on accepte que l’appliance, lors de son tout premier déploiement, soit en mode autorisation d’installation de composants externes. On en a besoin par exemple pour connecter une VSPC, déployer un management agent de la VSPC ou encore un management agent Veeam ONE. Il suffit de la passer à « oui », et une seconde clé permet de définir le timeout associé, réglé à 60 minutes par défaut.

La deuxième, High Availability, fonctionne exactement de la même façon : on la passe à « true », avec là aussi un timeout de 60 minutes par défaut. Elle permet de préparer l’appliance à rentrer dans un cluster en haute disponibilité. Car oui, désormais, les API sont là : en REST API, on peut demander à deux VSA de se mettre en cluster. Mais pour cela, il faut impérativement que les VSA soient en mode haute disponibilité accepté. Normalement, tout ceci se fait manuellement depuis le HMC, l’interface de gestion du host. Avec Autodeploy, c’est désormais automatisé.

Node Exporter enfin intégré nativement

Voilà une nouveauté qui va faire plaisir à beaucoup de monde : le Node Exporter est maintenant intégré nativement dans la 13.1.

Plus besoin d’embarquer un repo offline directement chargé dans l’ISO, plus de dépendances avec des RPM externes, et plus besoin d’ouvrir manuellement le firewall. Tout se pilote désormais via une simple commande PowerShell d’activation du partage de métriques. On peut même choisir d’activer ou non le SSL.

Dans le JSON, une nouvelle clé Node Exporter appelle directement la commande PowerShell correspondante, et vous retrouvez ensuite vos métriques en HTTP ou HTTPS sur l’adresse de votre VSA. Une clé dédiée au TLS fonctionne exactement sur le même principe.

Attention là aussi, c’est un breaking change : je l’ai retiré de la partie Infrastructure Appliance, puisque désormais tout est piloté depuis la VSA. Seule la VSA peut envoyer l’ordre d’activer le Node Exporter sur une VIA ou un repository.

Les rôles d’appliance sortent du GRUB

Autre changement majeur : la gestion des rôles au niveau des Infrastructure Appliances. Auparavant, on choisissait le rôle en amont, directement dans le GRUB. Maintenant, on le définit dans le fichier de configuration, via la clé appliance role.

Trois rôles sont possibles : VB Proxy, NAS Proxy et Linux Hardened Repository. Le choix du rôle déclenche ensuite la séquence spécifique correspondante. C’est beaucoup plus propre, et je comprends totalement ce choix : si l’on devait configurer deux ou trois types d’appliances différents, avec à chaque fois une variante single ou multi disk dans le GRUB, cela commençait à faire énormément d’entrées et devenait vraiment lourd à maintenir.

J’en ai profité pour renommer quelques types d’appliances au passage, car certains noms n’avaient plus vraiment de sens, notamment depuis que certaines options ont été fusionnées.

Le mode single disk, une vraie bonne idée

Une autre clé fait son apparition, spécifique aux Infrastructure Appliances : single disk. L’idée est de n’avoir qu’un seul disque pour son proxy, et c’est vraiment très pratique. Quand on déploie un proxy VMware, on n’a pas besoin de disque supplémentaire.

De la même façon, pour un hardened repository, on peut ne prendre qu’un seul disque et décider que le second, celui qui servira réellement de repository, soit monté directement au moment du setup grâce à la nouvelle fonctionnalité de montage NAS ou FC. C’est propre, souple, et ça simplifie franchement les déploiements.

Un fichier de configuration toujours plus complet

Dans le fichier de configuration, on retrouve bien sûr tous les paramètres habituels : admin, mot de passe, serveur NTP… À ce sujet, il est désormais possible de renseigner plusieurs serveurs NTP en les séparant par des virgules.

Et bien sûr, on y trouve désormais nos fameuses clés External Manager et High Availability, qui permettent de préparer nos VSA à être appairées avec une VSPC, un Veeam ONE, ou à monter en haute disponibilité.

Petit teasing : Autodeploy Web arrive

Avant de vous laisser, j’ai une petite surprise à vous partager. Je prépare une prochaine vidéo sur un projet qui me tient particulièrement à cœur : Autodeploy Web.

L’idée ? Un conteneur que vous déployez chez vous, et au lieu de lancer le script depuis votre PC pour personnaliser un ISO, vous pourrez le faire directement depuis une interface web, soit via un job, soit de façon assistée. J’espère sincèrement que ça vous plaira autant qu’à moi.

Et ce n’est pas tout : il sera aussi possible de déployer directement ce que vous avez créé, vos masters VSA et VIA, sur Proxmox, Hyper-V ou vSphere, de faire du remote kickstart, puis de connecter le tout entre eux via les REST API.

Voilà pour ce tour d’horizon des nouveautés de la 13.1 et de tout ce que vous pouvez désormais faire avec Autodeploy. Merci beaucoup d’avoir lu jusqu’au bout, et je vous dis à très vite pour la suite avec cette fameuse interface web. À toute !