VMware: Request a CatalogItem with the vRA API

VMware : Request a CatalogItem with the vRA API


Dans cet article on va faire un tour sur l’API Rest offerte par vRA. Le but va être de demander et supprimer une machine virutelle via Rest API.

Quelques notions avant de débuter

  • GET = récupérer une information
  • POST = envoyer une information
  • vRA CatalogItem = Blueprint ou Template disponible sous forme de services qu’on peut consommer via le portail vRAa. (IaaS, XaaS, etc).
  • vRA CatalogResource = Machine déjà provisioné qu’on peut reconfiguré, supprimer via le portail vRA


Accéder au portail Rest API de vRA

https://{{vra-fqdn}}/component-registry/services/docs

 

Accéder au Portail vRA

Sur notre portail vRA, on voit qu’on a 2 Blueprints de types IaaS proposés: Test_Linux et Windows2012R2
Le Test_Linux sera utilisée ici.

Outil Rest API

Plusieurs outils sont possibles pour générer des call APIs. Dans cet article, nous utilisons  PostMAN
Avec PostMAN, il est possible de créer des variables afin de gérer ces environnements. Nous avons un environnement vRA avec quelques variables intéressantes, notamment la variable “vra-fqdn” qu’on va énormément utilisé ou encore le username, tenant.

 

Récupérer le Token

La premire requête API sert à récupérer le Token ou jeton d’authentification (valide 24h).
Ce jeton sera par la suite utilisé pour tous les call APIs.

POST: https://{{vra-fqdn}}/identity/api/tokens

Content-Type application/json

La requête étant un POST, il est nécessaire de fournir des informations dans le corps de la requête (le body).
Grace à notre environnement, on peut directement utiliser nos variables. Pratique !


“username”: “{{username}}”,
“password”: “{{password}}”,
“tenant”: “{{tenant}}”
}

Une fois la requêtre prête, reste plus qu’à l’éxecuter: SEND!
On trouve la réponse qui comporte notre token en bas.

 

Utiliser le Token

Avant d’éxécuter cette requête, il est nécessaire de renseigner le Token qu’on a récupéré lors de la première étape.
Sans le token, aucune requête API ne fonctionnera.

Headers
Authoziation: Bearer “ID du Token”

 

Récupérer la liste des CatalogItems

GET: https://{{vra-fqdn}}/catalog-service/api/consumer/entitledCatalogitems

La requête nous donne 2 blocs, 2 CatalogItems.
Vous vous rappelez de nos 2 IaaS services sur le portal vRA? (Test_Linux & Windows2012 R2). Voici ces 2 CatalogItems.

En déroulant les accolades, on retrouve notre Test_Linux CatalogItem (IaaS Blueprint).
Notez l’ID de ce catalogItem.

Note: tout call API se fait à l’aide des IDs car unique!! 


Récupérer le Template du CatalogItem

https://{{vra-fqdn}}/catalog-service/api/consumer/entitledCatalogitems/{CatalogItemID}/requests/template

On remplace {{CatalogItemID}} par l’ID du CatalogItem “Test_Linux” récupéré à l’étape précédente

Le call nous donne les détails du Blueprint/Template: type de blueprint, CPU, RAM, Disk, etc.


Demander une VM à l’aide de ce CatalogItem

POST: https://{{vra-fqdn}}/catalog-service/api/consumer/entitledCatalogitems/{CatalogItemID}/requests

Ici, on va envoyer une requête pour déployer une nouvelle VM à l’aide de ce blueprint/template.
Ce qu’on peut également faire, c’est customisé notre VM, en indiquant des CPU/RAM/DISK spécifiques.

  • CPU = 2
  • Memory = 4096
  • Storage = 30

On clique sur SEND !
Status: 201 Created. Tout semble s’être bien passée.

La demande d’une VM (blueprint) est un type spécifique qu’on appelle “CatalogItemRequest”
Notre demande a également son propre ID
L’était de la requêtes est en “SUBMITTED”.


Récupérer l’état du CatalogItemRequest

GET: https://{{vra-fqdn}}/catalog-service/api/consumer/requests/{requestID}

{{RequestID}} est à remplacer par l’ID récupérer à l’étape précédente.
On voit que le state de la requête est en “IN PROGRESS”.  La VM est en provisionning


Vérification sur le portail vRA

 

Vérirication de notre VM avec ces 2 CPU et 4096 MB.

 

Récupérer la liste des CatalogResources

GET https://{{vra-fqdn}}/catalog-service/api/consumer/resources

La première question que vous pouvez vous poser est quelle est la différence entre CatalogItem et CatalogResource
CatalogItem = Blueprint qu’on souhaite demandé
CatalogResource = Blueprint provisionné. Notre machine qu’on utilise.

La requête nous donne bien le CatalogResource provisioné à l’étape précédente.
Name: CLD0229

 

List des Actions possible sur notre CatalogResource

https://{{vra-fqdn}}/catalog-service/api/consumer/resources/{resourceId}/actions

{{resourceID}} est à remplacé par l’ID du CatalogResource qu’on retrouve à l’étape précédente.
L’opération qu’on va utiliser ici est Destroy (vous devinez pourquoi).


Récupérer le template de l’action Destroy

GET https://{{vra-fqdn}}/catalog-service/api/consumer/resources/{resourceId}/actions/{resourceActionId}/requests/template

{{resourceActionID}} est à remplacer par l’ID récupérer à l’étape précedente (ID de l’action Destroy)

 

Exécuter la Destruction de notre CatalogResource

POST https://{{vra-fqdn}}/catalog-service/api/consumer/resources/{resourceId}/actions/{resourceActionId}/requests

Leave a Reply

Your email address will not be published. Required fields are marked *