IT memoirs

As a continuation to my Cloud Director automation story, I started to dig a bit more into API calls used for configuring Cloud Director. Process is fairly simple, just turn on network monitoring in chrome developer tools and you can see which API calls the HTML5 portal does when actions are initiated. I got couple basics done, adding vCenter and NSX-T manager, after which I already made quite significant learnings. One is that I now know why the API calls are not documented, they're completely inconsistent and there's pretty much no consistency across. Would be quite difficult to document :) In practice those two actions mean four API calls, three of them different. Add certificate as trusted (done twice, for both vCenter and NSX-T certificate) https://{vcd_url}/cloudapi/1.0.0/ssl/trustedCertificates Register vCenter https://{vcd_url}/api/admin/extension/action/registervimserver Register NSX-T https://{vcd_url}/api/admin/extension/nsxtManagers First when

Overview This story is about automating the deployment of VMware Cloud Director on Azure, done purely for exercise purposes but there's quite many re-usable components here. Setup is done in GitHub and overall orchestration is done by GitHub actions. Everything is in code in GitHub and each time there's a new push the previous setup is first deleted and then re-created. Everything except binaries and certificates, which are stored Azure blob storage and fetched from there using keys stored in GitHub secrets. The deployment consists of following component: VM running VMware Cloud Director Database in Azure Postgres PaaS Application gateway for portal access "load balancing" DNS in AWS Route 53 Yes, the title says on Azure but actually there's a bit of AWS also included in the form of public DNS hosting. In the details there's a bit reverse engineering about using undocumented API calls and other interesting bits. The actual code and pipel