Bonsoir tout le monde. Cloud Director, le nouveau nom de « vCloud Director » fait sans doute partie des produits assez méconnus de VMware, mais aussi des plus anciens. Il est vrai qu’il a eu une vie plus que tumultueuse depuis ses débuts avec « Lab Manager » jusqu’à Cloud Director 10.3, et ce, depuis plus de 10 ans. Cette nouvelle mouture, remise au gout du jour, full HTML, compatible avec NSX-T, est désormais particulièrement aboutie. Je vous propose, toujours dans le cadre de la construction d’un nouvel environnement de test&dev&qual, de passer la plupart des étapes d’installation et de configuration.
En effet, je connais personnellement vCloud Director depuis plus 8 ans maintenant, car il fait partie du socle monté en 2012 chez nous pour répondre à un besoin historique de service d’hébergement « HDS ». A cette époque NSX-T (encore dans les labs d’une start-up, Nicira) n’existait même pas en tant que produit et il fallait utiliser un composant d’isolation et de gestion de l’offre sécurité de VMware, « vShield », ancêtre de NSX-V. Nous avons suivi ses nombreuses évolutions, ainsi que la période étrange de sa « quasi disparition » des plaquettes commerciales de VMware, pour enfin revenir au devant de la scène il y a un peu plus de 2 ans.
Jusqu’à récemment il n’existait pas de « ova » simple à installer et à paramétrer pour démarrer une instance vCloud (il vous fallait une base Oracle spécifique, des cellules sous CentOS et l’installation de rpm spécifiques). Désormais, installer un Cloud Director est très simple et je vous propose de commencer cette série de billets par ce processus. Nous allons partir de la version 10.3, la dernière en date, dont la virtual appliance est disponible en téléchargement direct sur votre espace de travail VMware customer connect (et oui, tout change, il ne faut plus dire MyVMware, c’est has-been ..).
Le produit est basé sur plusieurs socles techniques (base de données séparaé, isolations logiques des composants …) qui sont variables en fonction de vos objectifs et ressources disponibles, mais, de base, il vous faut au moins une appliance (la primaire) ainsi qu’un répertoire NFS partagé capable d’être connecté à toutes les « cellules », fonctionnant de concert, pour constituer le cluster Cloud Director. Nous somme ici au sein d’un Lab, donc on va se contenter d’une seule instance et du répertoire réseau NFS. ça suffit amplement pour du test.
Les options d’installation de l’ova sont relativement standards, donc je ne vais pas m’étendre dessus, mais il est bon de préparer un peu vos DNS et autres plans d’adressage au préalable, histoire de ne pas être embêté par la suite. Voici toutes les étapes passée lors du déploiement, elles parlent d’elle-mêmes je pense :
… ce qu’on peut noter malgré tout c’est le sizing. Si une taille « small » suffit amplement pour mon usage, je vous conseille malgré tout, si vous avez de la place, de choisir au moins le medium, sachant que Cloud Director est en full java, la réactivité n’en sera que meilleure. D’autre part, vous constaterez que dans les paramètres réseau, on doit déclarer 2 IPs pour l’appliance, ainsi que spécifier, si nécessaire, des routes statiques complémentaires. C’est lié à la « position » d’une vrai vCloud en production : ce produit est en principe là pour être publiable et exposé sur Internet et par définition, être particulièrement sécurisé. De plus, les deux IPs permettent de séparer l’activité portail web (derrière un load-balancer WAF, par exemple) de celle de la prise de main technique des consoles de chaque VM hébergée via la solution. En gros, si vous souhaitez aller plus loin que de la curiosité ou du test interne, il vous faudra bien designer le projet et positionner correctement les différents composants pour que tout cela fonctionne bien avec le bon niveau de sécu. A mon avis, mes amis d’Ikoula, qui, précisément, utilisent Cloud Director et le commercialise (voir mon billet ici), ont du passer pas mal de temps la dessus ^^
Une fois installée, au premier lancement, vous devez initialiser l’instance elle-même, informations sur la base de donnée intégrée (PostgreSQL), point de montage du partage NFS, le compte administrateur etc. Pour le faire, il suffit se rendre sur l’IP native (eth0) de l’appliance avec le port 5480 et utiliser le compte root que vous avez saisi lors de l’installation de l’ova.
… je vous conseille d’attendre 3/4 minutes une fois cette étape franchie, pour être sûr que tout est bien lancé, avant de vous jeter sur le portail.
On y est presque, cliquez sur l’URL qui vous a été présenté dans l’assistant web précédent. Vous allez être redirigé sur le portail d’administration global. Cloud Director, une fois configuré, vous proposera des URLs spécifiques pour chaque Tenant créé dans l’interface, avec un affichage dédié et orienté « consommation » d’environnement IAAS cloud. La première chose à faire, de mon point de vue, c’est de paramétrer vos URLs « officielles », pour accéder au portail. En général, ces URLs sont accessibles directement depuis l’extérieur/le net afin de fournir un accès aux consoles pour chaque client. Elles sont donc importantes et sont la plupart du temps associées à des certificats publics dûment enregistrés auprès d’une autorité qui vous convient. Pour ce faire, rendez-vous dans la section « Administration » et puis dans la section « Public Addresses », enfin cliquez sur le petit bouton « EDIT » situé en haut du formulaire. Je vous conseille, au passage d’utiliser un Chrome/Safari/Firefox/Navigateur récent configuré en Anglais, les traductions VMware étant particulièrement troublantes, voir incompréhensibles (ce n’est que mon avis ^^).
… vous noterez que le dernier paramètre « VMware Cloud Director console proxy » ne vous demande pas une URL mais un nom de host ainsi qu’un port. Il s’agit de l’accès public pour pouvoir gérer les consoles des machines virtuelles. Ce port discute en SSL mais ce n’est pas du service Web à proprement parlé, donc attentions vis à vis des reverse proxy/load balancers que vous devrez peut-être installer en frontal. Dans l’example, j’ai indiqué une IP, la fameuse seconde IP de l’appliance car je n’ai pas besoin de plus, mais dans la pratique, il faudra que vous vous inquiétiez du certificat SSL de ce service, donc tant qu’à faire, utilisez toujours un FQDN. Une fois validé, re-connectez-vous directement avec cette nouvelle URL de portail, sinon, vous risquez des erreurs de sécurité. Cloud Director est assez pointilleux de ce point de vue-là.
L’installation initiale est terminée. La prochaine fois on passera à des choses plus intéressantes : la configuration des ressources techniques nécessaires pour délivrer du service IAAS/Cloud. A très vite !