VMware Cloud Provider Lifecycle Manager
In my professional career I spend quite a bit of time designing cloud solutions and products. I am always looking at ways to improve the deployment and day 2 operations of products to make operational teams more efficient, provide product consistency and remove the “human factor” which can lead to undesired results in deployments.
VMware Cloud Director https://www.vmware.com/au/products/cloud-director.html is part of my bread and butter so I was looking how I could follow my cloud solution mantra with VMware Cloud Provider Lifecyle Manager (VCPLCM) https://docs.vmware.com/en/VMware-Cloud-Provider-Lifecycle-Manager/index.html .
So what is VCPCLM and how does it provide deployment consistency and day 2 operations ? I am glad you asked,
VCPLCM allows for the creation of Cloud Director environments and the lifecycle of the platform for day 2 operations including software patching and certificates, Existing Cloud Director environments can also be imported to take over what would have normally been manual operations. VCPLCM has three components which are Environments, Datacenters and Tasks.
Lets start with Datacenters. While not mandatory to deploy a VMware Cloud Provider environment, VCPLCM provides integrations into the deployment of the platform with integrations which include vCenter, NSX, NSX ALB, and vROPs. The integrations allow VCPLCM to check the interoperability when Cloud Director is lifecycled and will flag an issue if identified.
The integrations are deployed as you would normally and then registered within VCPLCM. Below is an example of imported integrations into VCPLCM.
Moving onto Environments. This is deployment of VMware Cloud Director, VMware Chargeback, vCloud Usage Meter and RabbitMQ. These are all add-on applications for Cloud Provider platforms however not a requirement as a provider not provide the application extensions or choose another method of lifecycle.
The application environments can be added into a VMware Cloud Director deployment and also have interoperability checked and flagged if not compliant. The difference with these application environments is they can be life-cycled with later software versions, scale the application (for example adding more VCD Cells) or have certificates updated by VCPLCM to ensure interoperability before updating a Cloud Director environment.
Blow is an example of what actions are available to a deployed Cloud Director environment.
Below is an example of updating RabbitMQ.
There is one caveat to all this deployment and lifecycle goodness, and that all the OVA’s used for the deployment and updating of applications need to be stored on VCPLCM which can add up to quite a bit of capacity. The location path on the appliance for the OVA’s is as fpllows.
vcplcm@vcplm [ /cplcmrepo ]$ pwd
vcplcm@vcplm [ /cplcmrepo ]$ ls -lr
drwxrwxrwx 16 root root 189 May 7 13:10 vropsta
drwxrwxrwx 28 root root 4096 May 7 13:10 vcd
drwxrwxrwx 6 root root 60 May 7 13:10 usage
drwxrwxrwx 4 root root 33 May 7 13:10 rmq
So depending on your cost of storage you may want to move the path off to NFS storage.
For example 192.168.1.125:/nfs/vcplm/cplcmrepo 47G 7.1G 40G 16% /cplcmrepo
Well that’s the end of this blog so I hope I have enlightened you to go take a look and see if it suitable for your existing or net new deployments. The best part is if you deploy an Environment or Datacenter from VCPLCM is does not delete your production systems, it just deletes it from the VCPLCM database.
I am hoping do more around Cloud Director as it a great platform multi-tenancy so stay tuned for more blogs on the subject.