L’été est là et il me permet de me poser un peu pour vous écrire un nouvel article sur Cloud Assembly. Mais avant d’aller plus loin, j’aimerais partager avec vous la vision de VMware sur le Cloud Public. Aujourd’hui la tendance est plutôt au Multi-Cloud car, il est vrai, qu’aucun Cloud Provider ne sait satisfaire entièrement les besoins métiers d’une entreprise.
C’est pour cette raison que les DSI font de plus en plus le choix de l’ouverture d’un IT connecté vers différents Clouds Providers. Fort de ce constat, VMware à décidé de proposer des services à valeurs ajoutées orientés multi-clouds et en mode Software As a Service.
Cette approche permet notamment aux entreprises de pouvoir consommer des outils sur une approche totalement ouverte et agnostique en terme de Cloud Provider.
Pour rappel, VMware est présent et en partenariat avec l’ensemble des plus grands Clouds Providers tels que AWS, Azure, Google, Alibaba, IBM, OVH. Cette stratégie permet à VMware d’accélerer La transformation et la migration vers le cloud public en transparence. Les entreprises peuvent migrer très facilement vers une offre comme VMware Cloud on AWS ou vers les VMware Clouds Providers Certified (Azure, Google, OVH, IBM) et ce, sans arrêt de la production.
Comment rendre les cloud invisibles ?
En mettant à disposition auprès des entreprises des outils unifiés permettant de gérer, consommer, modéliser et opérer l’ensemble des Clouds (Privé, Public ou Hybrid)
Cette approche existe déjà depuis quelques années chez VMware avec la suite « vRealize Suite » qui est composée d’outils tels que :
- vRealize Automation
- vRealize Operation
- vRealize Log Insight
- vRealize Network Insight
- vRalize LifeCycle Manager
Cloud Automation Services est une offre basée en SaaS et composée de trois produits permettant une gestion et une automation des différents Clouds Publics
La composition de cette approche se décline en trois logiciels :
- Cloud Assembly
- Service Broker
- Code Stream
INTRODUCTION
Cloud assembly est en quelque sorte le vRealize Automation des temps modernes.
Le look change radicalement et la conception aussi. Il permet d’être beaucoup plus agile et d’apporter une véritable approche DevOPS et Infrastructure as Code notamment sur la construction des blueprints.
GUI or IAC as you want !
Le développeur ou l’architecte (Infrastructure/Applicatif) peut utiliser l’interface web pour concevoir son blueprint mais aussi, il va pouvoir disposer d’une approche Infrastructure As Code en simultanée de la construction de son blueprint en graphique. C’est un élément très différenciateur par rapport à vRealize Automation et cela va plaire à beaucoup de développeur ou pour les personnes qui sont familiarisées avec le YAML. Je conseille vivement à toutes les personnes qui souhaitent aller vers Cloud Assembly de capitaliser sur certains YAML Terraform qu’ils pourraient avoir pour les « injecter » dans Cloud Assembly.
API First for Cloud Assembly
Cloud Assembly fournit une couche d’API. Elle peut servir notamment pour des outils tiers tels que Pivotal Cloud Foundry ou Pivotal Kubernetes Service.
Cette couche API permet notamment d’inclure dans un cycle d’automatisation Cloud Assembly pour pouvoir déclencher certaines actions. ( Déploiement d’une application à travers une API)
Multi Cloud ?
Cloud Assembly supporte bien entendu en OnPremise vSphere et NSX-T vSphere mais également il s’interconnecte avec AWS , Azure, GCP ainsi que VMware Cloud on AWS
Cloud Natif Service c’est parti pour un tour !
C’est pour moi probablement la meilleure feature qui puisse exister dans Cloud Assembly avec la possibilité de consommer des services natifs AWS ou Azure au sein d’un blueprint. Vous pouvez designer une stack applicative qui utilise une machine virtuelle vSphere et une database RDS en backend sur AWS par exemple.
Configuration Cloud Assembly
Déploiement d’un Cloud Proxy Data Collector
Dans mon cas je dispose d’un environnement en OnPrem avec un vCenter et 4 ESXIs. Il faudra donc télécharger et déployer une machine virtuelle appellée Cloud Proxy permettant d’interfacer Cloud Assembly avec votre vCenter on premise. Elle joue en quelque sorte le rôle de Proxy.
Quelques pré-requis en vrac…
- Data Collector has to have internet access, or using a Network Proxy
- HTTPS port 443 open to outgoing traffic with access through the firewall to:
- *.vmwareidentity.com
- gaz.csp-vidm-prod.com
- *.vmware.com
Commencer par vous connecter à la console Cloud Assembly avec votre compte.
Cliquer sur le menu Cloud Proxies puis sur le bouton New.
Cliquer ensuite sur le bouton Download OVA puis déployez votre OVA dans votre vCenter OnPremise
Connectez-vous à votre vCenter Server, cliquez avec le bouton droit de la souris sur un cluster et sélectionnez Déployer le modèle OVF.
- Cliquez sur Sélectionner modèle, puis sur URL. Renseignez l’URL qui vous a été generé auparavant.
- Saisissez les informations requises. Ne cliquez pas encore sur Suivant.
-
Entrez le nom de la machine virtuelle du Data Collector
-
Pour le mot de passe de l’utilisateur root, choisissez un mot de passe unique. Il n’est pas nécessaire qu’il corresponde au mot de passe du vCenter.
-
Collez le token que vous avez copié quand vous avez téléchargé votre OVA
Si vous utilisez un proxy réseau pour vous connecter à Internet, vous devez fournir ces informations.
Si vous utilisez DHCP dans votre réseau vCenter, n’entrez aucune information. Si vous n’utilisez pas DHCP, vous devez fournir des informations pour chaque paramètre. Cliquez sur Suivant.
-
- Vérifiez vos données de configuration. Cliquez sur Terminer.
- Lorsque l’OVA du Collecteur de données est déployé avec succès, lancez le Collecteur de données..
- Pour vérifier que votre Collecteur de données fonctionne, vérifiez sous l’onglet VMs dans la liste de vos machines virtuelles pour vous assurer qu’il est sous tension.
Retourner sur Cloud Assembly, sur lequel vous devriez voir apparaitre votre DataCollector
Création d’un Cloud Account
Une fois que le DataCollector est déployé dans votre infrastructure, vous devez créer un cloud account qui permettra de mettre en relation votre vCenter votre avec votre DataCollector.
Cliquer sur le menu Cloud Account puis cliquer sur Add Cloud Account
Remplir les champs nécessaires à la connexion à votre vCenter :
- URL de votre vCenter
- Sélectionnez votre proxy dans le menu déroulant
- Renseignez votre login et mot de passe du vCenter
- Définissez un nom pour votre cloud account
- Cochez le ou les clusters que vous souhaitez à votre Cloud Account.
- Vous pouvez également ajouter votre endpoint NSX, pour ma part je ne l’ai pas fait pour le moment car je n’ai pas dans cet environnement de NSX configuré (cela viendra par la suite…)
- Ajoutez le tag que vous souhaitez, pour ma part, mon environment s’appelle « sphinx » j’ai donc rajouté env:sphinx comme tag. Nous allons voir plus tard que la notion de TAG est assez important dans Cloud Assembly
Une fois que vous avez validé votre Cloud account vous devriez le voir apparaitre dans le menu Cloud Account comme ceci :
Création d’une Cloud Zone
Une Cloud Zone définit un ensemble de ressources de calcul pour un type de compte cloud, tel que AWS, Azure ou vSphere, dans une région de compte spécifique qui sont utilisées lorsque vous déployez un Blueprint. Les cloud zones sont spécifiques aux projets que nous détaillerons par la suite.
Pour créer une nouvelle Cloud Zone, vous devez allez dans le menu Cloud Zones puis cliquer sur le bouton New Cloud Zone
Cloud Zone
- Renseignez dans le champ Account/ region votre cloud account précedemment configuré
- Précisez le nom de votre Cloud Zone
- Sélectionnez la policy de placement que vous souhaitez
- Default : Placez les ressources de calcul sur les hôtes de manière aléatoire.
- binpack : Placez les ressources de calcul sur l’hote le plus chargé.
- Spread : Placez les ressources de calcul de manière égale sur tous les hôtes disponibles.
- Optionnel : Vous pouvez sélectionner un folder dans votre vCenter pour placer les machines directement dans ce folder.
- Optionnel : Rajouter un tag afin de pouvoir définir votre CloudZone.
Flavor Mapping
La section Flavor Mapping vous permet de définir la taille de vos déploiements sous forme de « T-SHIRT Size ».
Dans mon cas j’ai voulu créer 3 Flavor Mapping (Small,Medium,Large) qui me permet de définir des caractéristiques de base en vCPU et RAM.
La partie Flavor mapping sera utilisée lors de la création d’un blueprint.
Pour définir un nouveau Flavor Mapping Cliquer sur le menu Flavor Mapping à gauche puis sur le bouton New Flavor Mapping
Network Profile
Dans mon cas j’ai sélectionné trois Clouds Accounts (vSphere, AWS, Azure) pour définir des tailles d’image que je souhaite avoir pour cette section.
IMAGE MAPPING
L’image mapping permet de lier un template (vSphere,AWS,Azure).
Dans mon environnement vSphere je dispose d’un template Linux de base CentOS 7 permettant de réaliser mes différents déploiements.
La notion de Network Profile avec vRealize Automation reste à peu près la même. Il vous faudra donc créer votre Network Profile si vous souhaitez attacher une machine virtuelle à un réseau
Accédez à Infrastructure > Configurer > Network Profil.
- Cliquez sur + New Network Profile
- Dans l’onglet Sommaire, Pour le compte / la région, cliquez sur Rechercher des régions et sélectionnez votre région.
- Entrez un nom de profil de réseau : Profil de réseau Exemple : mle-sphinx-production
- Saisissez un tag de capacité : environnement:Production
Dans l’onglet Network, sélectionnez + Add Network et sélectionnez le(s) réseau(s) découvert(s) à utiliser lors du provisionnement d’une VM.
Sélectionnez les réseaux ajoutés et attribuez un tag pour chaque réseau, par exemple ici je configure le tag network :production pour mon Port Group Production
Séléctionnez le réseau et cliquez sur Manage IP, pour définir l’ensemble des adresses IP qui peuvent être réservées pendant le provisioning.
Vous avez plusieurs type de network profile dans Cloud Assembly :
J’ai coché volontairement la case « Do not create on-demand network »
Vous avez également la possibilité de créer un réseau isolé qui sera privé, en cochant la case « Create an on-demande network »
STORAGE Profile
Un profil de stockage est un ensemble de règles spécifiques au cloud qui permettent à l’administrateur du cloud de définir le stockage pour une région en particulier. Les politiques de stockage comprennent différents paramètres pour que votre déploiement soit positionné sur le bon datastore. Dans mon cas j’ai crée un profil de stockage permettant de placer l’ensemble de mes VMs sur mon Datastore vSAN automatiquement.
Pour créer un nouveau profil de stockage:
- Cliquez sur le menu à gauche Storage Profile
- Cliquez sur + New storage Profile
- Entrer le nom d’un Storage Profile
- Définir une politique de stockage (en l’occurence j’ai choisi la default Policy de vSAN)
- Choisir son Datastore
- Choisir le type de provisionnement (Thick ou Thin)
- Optionnel : Possibilité de limiter les IOPS.
Projet
La création d’un projet est la dernière étape de la configuration de Cloud Assembly. Il permet de créer une enveloppe logique pour pouvoir créer des blueprints à l’intérieur de ce projet.
Pour créer un nouveau projet cliquez dans le menu de gauche sur Project puis sur +New Project
- Dans la section Summary , précisez le nom de votre projet.
- Dans la section User, vous pouvez ajouter les utilisateurs faisant partis de ce projet.
- Dans la section Provisionning, vous devez ajouter votre Cloud Zone
- Optionnel : Vous pouvez ajouter un Cluster Kuberrnetes à votre projet et également avoir une intégration avec un écosysteme externe (type Ansible)
Conclusion
J’espère que ce premier article sur Cloud Assembly vous aura permis de mieux comprendre et appréhender le produit, dans un prochain article nous allons voir comment construire un premier blueprint et l’executer sur un environnement On-Premise.
Bonnes vacances et à très vite pour un prochain article !
Mika.
