Terraform Cloud Director Provider v3.13.0 is available now, adding support for Cloud Director 10.6 with many new features and improvements.
Extending VCD Functionality with Solution Add-Ons
Solution Add-Ons extend Cloud Director offering with value-added functionalities. One can manage the resources and life cycle of solutions that are custom-built to extend the functionality of VMware Cloud Director.
A Solution Add-On is the representation of a solution that is custom built for Cloud Director in the extensibility ecosystem. It encapsulates UI and API Cloud Director extensions together with their backend services and lifecycle management. Solution Add-Ons are distributed as .iso files and can contain numerous elements: UI plugins, vApps, users, roles, runtime defined entities, and more.
Terraform VCD Provider 3.13 adds support for Solution Add-Ons with the following new resources and data sources:
On top of that, there are two new resources (with their data sources, as usual) for Data Solution configuration and publishing to tenants:
VMware Cloud Director extension for Data Solutions is a Solution Add-On for Cloud Director, which enables multi-tenancy customers to deliver a portfolio of on-demand caching, messaging and database software. Service providers can offer their tenants an integrated solution, which allows them to operate and manage data-as-a-service across private clouds and sovereign clouds.
There is a new guide page. For those preferring hands-on experience, there are also HCL examples.
Solution Add-On Configuration Example (Data Solution Extension)
The below code covers end to end setup of a Data Solution Extension in a green field – it covers configuration of Solution Landing Zone, and then creation, instantiation and publishing of a Solution Add-On.
Note: For brevity – these examples lack some referenced resource/data source definitions. A complete set of HCL scripts can be seen in the HCL examples and better explained in the Data Solution Guide Page.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
|
resource “vcd_solution_landing_zone” “slz” { org = var.vcd_solutions_org
catalog { id = vcd_catalog.solution_add_ons.id }
vdc { id = data.vcd_org_vdc.solutions_vdc.id is_default = true
org_vdc_network { id = data.vcd_network_routed_v2.solutions.id is_default = true }
compute_policy { id = data.vcd_org_vdc.solutions_vdc.default_compute_policy_id is_default = true }
storage_policy { id = data.vcd_storage_profile.solutions.id is_default = true } } }
resource “vcd_solution_add_on” “dse14” { catalog_item_id = data.vcd_catalog_media.dse14.catalog_item_id add_on_path = var.vcd_dse_add_on_iso_path auto_trust_certificate = true
depends_on = [vcd_solution_landing_zone.slz] }
resource “vcd_solution_add_on_instance” “dse14” { add_on_id = vcd_solution_add_on.dse14.id accept_eula = true name = “dse-14”
input = { delete–previous–uiplugin–versions = true }
delete_input = { force–delete = true } }
resource “vcd_solution_add_on_instance_publish” “public” { add_on_instance_id = vcd_solution_add_on_instance.dse14.id org_ids = [data.vcd_org.dse–consumer.id] publish_to_all_tenants = false }
|
Dynamic Schema Validation for Solution Add-On Instantiation
Each Solution Add-On contains its own inputs that need to be validated and resource vcd_solution_add_on_instance has a mechanism for dynamic input validation in the guide.
Configuring and Publishing Data Solutions
Once the DSE Solution Add-On is instantiated and published, a provider can leverage DSE specific resources to perform registry configuration details and publish Data Solution to tenants.
|
|
resource “vcd_dse_registry_configuration” “dso” { name = “VCD Data Solutions” use_default_values = true }
resource “vcd_dse_registry_configuration” “mongodb-community” { name = “MongoDB Community” use_default_values = true }
resource “vcd_dse_solution_publish” “mongodb-community” { data_solution_id = vcd_dse_registry_configuration.mongodb–community.id
org_id = data.vcd_org.dse–consumer.id } |
Auto-Scaling Support for Container Service Extension Kubernetes Cluster
The Kubernetes Autoscaler can automatically adjust the size of worker pools in CSE. Terraform VCD Provider 3.13 allows to configure the auto-scaling capabilities for every worker pool by specifying the minimum and maximum nodes. This can be used instead of the existing machine_count argument:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
|
resource “vcd_cse_kubernetes_cluster” “my_cluster” { name = “my-cluster” # …
# Normal worker pool with fixed number of machines worker_pool { machine_count = 1
name = “node-pool-1” disk_size_gi = 20 sizing_policy_id = data.vcd_vm_sizing_policy.tkg_small.id storage_profile_id = data.vcd_storage_profile.sp.id }
# Worker pool with the new Autoscaler capabilities worker_pool { autoscaler_min_replicas = 2 autoscaler_max_replicas = 10
name = “node-pool-2” disk_size_gi = 20 sizing_policy_id = data.vcd_vm_sizing_policy.tkg_small.id storage_profile_id = data.vcd_storage_profile.sp.id } }
|
When autoscaler_max_replicas and autoscaler_min_replicas are set in any worker pool, the Kubernetes Autoscaler is automatically deployed to the cluster, in order to manage the worker pools that are configured this way. More details about the Autoscaler can be read in the official FAQ document.
OpenID Connect Support
OpenID Connect is an authentication layer on top of the OAuth 2.0 protocol, which allows clients to receive information about authenticated sessions and end-users. You can now configure organizations in VMware Cloud Director with Terraform VCD Provider 3.13 to use this identity provider solution by using the vcd_org_oidc resource:
|
|
data “vcd_org” “company1” { name = “company1” }
resource “vcd_org_oidc” “oidc” { org_id = data.vcd_org.my_org.id enabled = true prefer_id_token = false client_id = “superClient” client_secret = “i-am-a-secret” max_clock_skew_seconds = 60 wellknown_endpoint = “https://my-idp.company1.com/oidc/.well-known/openid-configuration” } |
In the example above, a well-known endpoint is used to retrieve all the needed configuration parameters. When using this kind of endpoint, one can also override any of the obtained values, if needed:
|
|
resource “vcd_org_oidc” “oidc” { org_id = data.vcd_org.my_org.id enabled = true prefer_id_token = false client_id = “superClient” client_secret = “i-am-a-secret” max_clock_skew_seconds = 60 wellknown_endpoint = “https://my-idp.company1.com/oidc/.well-known/openid-configuration”
# Overrides: access_token_endpoint = “https://my-other-idp.company2.com/oidc/token” userinfo_endpoint = “https://my-other-idp.company2.com/oidc/userinfo” } |
This resource can be used either by providers, to configure OIDC for the System organization, or by tenants, to configure OIDC for each tenant.
VDC Template Support
Providers can now create and manage VDC Templates with the vcd_org_vdc_template resource. A VDC template specifies a configuration for an organization VDC and, optionally, an Edge Gateway and organization VDC network.
The configuration of a VDC Template is very similar to how configuring a VDC looks like:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
|
resource “vcd_org_vdc_template” “tmpl1” { name = “myTemplate” description = “Requires System privileges” tenant_name = “myAwesomeTemplate” tenant_description = “Any tenant can use this” allocation_model = “AllocationVApp”
compute_configuration { cpu_limit = 0 cpu_guaranteed = 20 cpu_speed = 256 memory_limit = 1024 memory_guaranteed = 30 }
provider_vdc { id = data.vcd_provider_vdc.pvdc1.id external_network_id = data.vcd_external_network_v2.ext_net.id }
provider_vdc { id = data.vcd_provider_vdc.pvdc2.id external_network_id = data.vcd_external_network_v2.ext_net.id }
storage_profile { name = “*” default = true limit = 1024 }
network_pool_id = data.vcd_network_pool.np1.id
readable_by_org_ids = [ data.vcd_org.org.id ] } |
Once the VDC Template is created, it can be instantiated by any provider, or by any tenant user with the required rights, and if it was set in the readably_by_org_ids argument. In order to do that, one can leverage the vcd_org_vdc_template_instance resource:
|
|
resource “vcd_org_vdc_template_instance” “my_instance” { org_vdc_template_id = vcd_org_vdc_template.tmpl1.id name = “myInstantiatedVdc” description = “A new VDC” org_id = data.vcd_org.org.id
# This guarantees that removing this resource from HCL won’t remove # the instantiated VDC. Set it to “true” to remove the VDC when this # resource is removed. delete_instantiated_vdc_on_removal = false delete_force = false delete_recursive = false } |
Users can control what to do when the vcd_org_vdc_template_instance resource is removed, with the delete_instantiated_vdc_on_removal flag and auxiliary flags delete_force and delete_recursive. If they don’t want the resource to delete the VDC when it is removed from HCL configuration, delete_instantiated_vdc_on_removal=false will avoid precisely that. This is useful when the instantiated VDC is imported as a next step, and completely managed by a vcd_org_vdc resource, because users can then discard the vcd_org_vdc_template_instance code block without any side effect.
VCD and Organization Association (Multi-Site)
An association between VCDs is accomplished by the collaboration between the administrators of the two sites (or the coordinated action of an administrator that own both VCDs). The data source vcd_multisite_site_data allows the administrator to collect the association data needed to set up the operation. On the other side, the administrator of the receiving VCD will use the resource vcd_multisite_site_association to set the connection. When both sides have performed both operations, the association is done.
Similar operations (using the data source vcd_multisite_org_data and resource vcd_multisite_org_association are performed to create an association between organizations. There are 5 data sources and 2 resources to perform the various tasks. Since it may be confusing to understand what to use and when, we have also introduced a general purpose Site and Org association guide.
Here’s an example:
The administrator of site 1 collects the data as follows, saving it to file site1.xml
|
|
data “vcd_multisite_site_data” “site1” { download_to_file = “site1.xml” } |
The administrator of site2 will then create the association:
|
|
resource “vcd_multisite_site_association” “site2-site1” { association_data_file = “site1.xml” } |
After that, the two administrators swap roles and run the same operations in reverse order (site2 data collection and site1 association).
There are two full examples about site association and organization association in the repository.
List of New Resources and Data Sources
2 new guide pages:
11 new resources:
13 new data sources:
There are more features and enhancements, which you can see in the project’s changelog. And, as always, we are awaiting your feedback and suggestions in GitHub Issues and #vcd-terraform-dev Slack channel (https://the-code-community.slack.com).
Last but not least, there is a new version v2.25.0 of Go SDK for VMware Cloud Director.
