Note: For this post, I used a pre-GA versions of DSM 2.1 and DSM Supervisor Service. This the UI screenshots captured for this blog post may slightly differ from what you observe when using the GA version. However the workflow should be identical.
Install the DSM Consumption Operator Supervisor Service
With that in mind, let’s go ahead and see the steps involved in adding this new Service to the Supervisor. The steps are very similar to the steps that we followed in part 2 for the installation of the CCI Service. Navigate to the Workload Management section of your vSphere Client, select Services and click on the box to Add a New Service. This opens the following dialog:
At this point, upload the YAML manifest to install the Data Services Manage Consumption Operator as a Supervisor Service. The Package manifest is available at this repo. The contents of that YAML manifest which I used (again, noting that this is pre-GA) looked like this. The GA version will be slightly different, with different names, images and dates. Always pick up the latest version from the repo.
apiVersion: data.packaging.carvel.dev/v1alpha1 kind: Package metadata: name: dsm.fling.vsphere.vmware.com.1.0.0-72-ge553acb spec: refName: dsm.fling.vsphere.vmware.com version: 1.0.0-72-ge553acb releasedAt: "2024-06-21T18:58:59Z" template: spec: fetch: - imgpkgBundle: image: dsm-docker-dev-local.usw5.packages.broadcom.com/dsm-consumption-operator/dsm-consumption-operator-supervisor:1.0.0-72-ge553acb template: - ytt: ignoreUnknownComments: true paths: - config/ - kbld: paths: - .imgpkg/images.yml - '-' deploy: - kapp: {} --- apiVersion: data.packaging.carvel.dev/v1alpha1 kind: PackageMetadata metadata: name: dsm.fling.vsphere.vmware.com spec: displayName: Data Services Manager Consumption Operator shortDescription: DSM
Once loaded, the Service Details should look something similar to the following, but again showing the latest version of the operator (and not the pre-GA version that I used for this blog post):
Click Finish. Now the Data Service Manager should have its own Service window. Click on the Actions, and select the option to Install on Supervisors, just like we saw with the CCI service in part 2.
Now we need to add our next YAML Service Configuration. This Values YAML manifest contains the authorisation credentials for your Data Services Manager, the DSM URL as well as the Certificate of Authority for the DSM appliance. It also contains field such as which Infrastructure policies can be used when deploying databases and which backup locations can be used. The Values manifest is once again available at this repo. Here is a sample values manifest with the various entries populated. The DSM root CA can be retrieved from the DSM appliance at /opt/vmware/tdm-provider/cert/provider-ca-cert.pem.
Note that anonymous pull is enabled on the image server, so simply add the server name to the imagePullSecretGeneration section and leave the password and username as blank (or some misc. values). [Update]: In later releases, I have been informed that complete imagePullSecret section will be unnecessary and can be omitted completely. Customers need only include the part of the manifest below starting at dsm:.
imagePullSecret: registry-creds imagePullSecretGeneration: create: password: ******** server: projects.packages.broadcom.com username: ******** dsm: authSecretName: dsm-auth-creds authSecretGeneration: create: endpoint: https://192.168.0.120 user: dsmadmin@rainpole.com password: VMware123! rootCA: |- -----BEGIN CERTIFICATE----- MIIDUTCCAjmgAwIBAgIGAZA14OxfMA0GCSqGSIb3DQEBCwUAMFkxCzAJBgNVBAYT AlVgobbeldy-gukVDANEU00xFTATBgNVBAsMDERNUyBQcm92aWRlcjElMCMGCSqG SIb3DQEJARYWZHNtX3N1cHBvcnRAdm13YXJlLmNvbTAgFw0yNDA2MTcxMzQwNTFa GA8yMDc0MDYyMDEzNDA1MVgobbeldy-gukMCVVMxDDyyyyAKBgNVBAoMA0RTTTEV MBMGA1UECwwgobbeldy-gukpZGVyMSUwIwYJKoZIhvcNAQkBFhZkc21fc3VwcG9y dEB2bXdhcmUuY2gobbeldy-gukhkiG9w0BAQEFAAOCAQ8AMIIxxBCgKCAQEAwub5 jlJAHy9FBS6eJPamWJoKRNbKd9gobbeldy-gukNTNgUsXMPxxyyz2U09Z56L5vtR 5Me6xQAyBp+hBAtYJ5Ii+DGrYoNsxv8XdgbzWM5bZG2+GkXzsIGtTah/v1qDD7pH 53F3+eMadz7ihYsqgobbeldy-gukXNsa8UqR3/PZbKEQBMHMGUq7pn12HJ6tUwzL fMpGjDJRqn3CcdJ1lC8gkf9cL50J80XxhihYEq4yV3v1vgobbeldy-gukN4KKO8g /klBemsoAEB4txgg3ETfq1UOiiRLUFP0isuHvHbdJkiRE+X8jrkBjP7WZpN6u517 wD+FrObSxhLVNH3gDwIDA45QABox560wGzgobbeldy-gukYwDAYDVR0TBAUwAwEB /zANBgkqhkigobbeldy-gukAQEAkDZWp8UNq6xhN6A55m+lK+jE93gZHoS/bbjOf QEBaBUdgKONRhxtNYe890FA2WMywaaJspscoZj9gobbeldy-gukozpKAI+tw7ULS +F1N7hkFkmfsF3456789WSe9pgobbeldy-gukDaf0TDGBMIbcg6Wlr7Zu1/dpGdO 6p6abcdefghijYyFMcqjrmagobbeldy-guktTsMKvQO+fzsWEMK8O89Z7AK4zOvK bzzSvxjNavoVimc4gGqB28fJ8NyxqVmggInJFXLAu8Pvon8sIqnt7H6XDLGop/S8 gm8wGRSjKredbNrW10/Yn259y7+y8XEMeR8w1dj5CMp6zfXCDw== -----END CERTIFICATE----- allowedInfrastructurePolicies: - demo allowedBackupLocations: - db-backups applyToNamespaces: backupLocations: - db-backups infrastructurePolicies: - demo selector: matchAnnotations: vmware-system-resource-pool: "*" enableClusterScoped: true consumptionClusterName: SUPERVISOR
Once the YAML manifest is added to the Service, click OK.
After a few moments, the DSM Consumption Operator should enter a Configured State:
If for some reason it does not, you can check the state of the objects in the CCI Namespace for DSM. Here is an example of what a working deployment looks like from my environment, where xx.yy.zz.42 is the obfuscated IP address of my Supervisor API server. Once logged in, switch contexts to the DSM namespace and display the objects to make sure they are running. Examine the Pod logs if there are issues.
% kubectl vsphere login --server=xx.yy.zz.42 --insecure-skip-tls-verify \ --vsphere-username administrator@vsphere.local Password: ******** Logged in successfully. You have access to the following contexts: xx.yy.zz.42 amaury-ns svc-cci-service-domain-c144 svc-dsm-domain-c144 If the context you wish to use is not in this list, you may need to try logging in again later, or contact your cluster administrator. To change context, use `kubectl config use-context <workload name>` % kubectl config use-context svc-dsm-domain-c144 Switched to context "svc-dsm-domain-c144". % kubectl get all NAME READY STATUS RESTARTS AGE pod/dsm-consumption-operator-controller-manager-78cbd79dcd-9dd29 1/1 Running 0 112m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/dsm-consumption-operator-webhook-service ClusterIP 10.96.0.137 <none> 443/TCP 25h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/dsm-consumption-operator-controller-manager 1/1 1 1 25h NAME DESIRED CURRENT READY AGE replicaset.apps/dsm-consumption-operator-controller-manager-78cbd79dcd 1 1 1 25h NAME COMPLETIONS DURATION AGE job.batch/dsm-consumption-operator-mutating-webhook-configuration-patch 1/1 10s 25h job.batch/dsm-consumption-operator-validating-webhook-configuration-patch 1/1 20s 25h job.batch/dsm-consumption-operator-webhook-server-cert-create 1/1 10s 25h NAME STATUS backuplocationbinding.databases.dataservices.vmware.com/db-backups Ready NAME TYPE ENDPOINT BUCKET backuplocation.databases.dataservices.vmware.com/db-backups https://192.168.0.200:9000 backuplocation.databases.dataservices.vmware.com/default-provider-backup-repo https://192.168.0.200:9000 backuplocation.databases.dataservices.vmware.com/default-provider-log-repo https://192.168.0.200:9000 NAME STATUS AGE infrastructurepolicy.infrastructure.dataservices.vmware.com/demo Ready 25h NAME STATUS infrastructurepolicybinding.infrastructure.dataservices.vmware.com/demo Ready NAME CPU MEMORY vmclass.infrastructure.dataservices.vmware.com/large 8 16 vmclass.infrastructure.dataservices.vmware.com/medium 4 8 vmclass.infrastructure.dataservices.vmware.com/small 2 4 NAME VERSION SERVICE TYPE APPROVAL AGE dataserviceversion.releases.dataservices.vmware.com/12.19---vmware.v2.1.0-rc.31-postgres 12.19+vmware.v2.1.0-rc.31 vmware-sql-postgres Enabled 25h dataserviceversion.releases.dataservices.vmware.com/13.15---vmware.v2.1.0-rc.31-postgres 13.15+vmware.v2.1.0-rc.31 vmware-sql-postgres Enabled 25h dataserviceversion.releases.dataservices.vmware.com/14.12---vmware.v2.1.0-rc.31-postgres 14.12+vmware.v2.1.0-rc.31 vmware-sql-postgres Enabled 25h dataserviceversion.releases.dataservices.vmware.com/15.7---vmware.v2.1.0-rc.31-postgres 15.7+vmware.v2.1.0-rc.31 vmware-sql-postgres Enabled 25h dataserviceversion.releases.dataservices.vmware.com/16.3---vmware.v2.1.0-rc.31-postgres 16.3+vmware.v2.1.0-rc.31 vmware-sql-postgres Enabled 25h dataserviceversion.releases.dataservices.vmware.com/8.0.29---vmware.v2.1.0-rc.31-mysql 8.0.29+vmware.v2.1.0-rc.31 vmware-sql-mysql Enabled 25h dataserviceversion.releases.dataservices.vmware.com/8.0.31---vmware.v2.1.0-rc.31-mysql 8.0.31+vmware.v2.1.0-rc.31 vmware-sql-mysql Enabled 25h dataserviceversion.releases.dataservices.vmware.com/8.0.32---vmware.v2.1.0-rc.31-mysql 8.0.32+vmware.v2.1.0-rc.31 vmware-sql-mysql Enabled 25h dataserviceversion.releases.dataservices.vmware.com/8.0.34---vmware.v2.1.0-rc.31-mysql 8.0.34+vmware.v2.1.0-rc.31 vmware-sql-mysql Enabled 25h
You can also run some commands that ensure that CCI is communication correct to DSM. For example, to check the Infrastructure Policy Bindings (ibp), run:
% kubectl get ipb NAME STATUS demo Ready
To check the Backup Location Bindings (blb):
% kubectl get blb NAME STATUS db-backups Ready
These match what we had placed in the YAML manifest earlier, so it does seem that communication is working correctly. Let’s now switch over to Aria Automation, and verify everything is working as expected.
Deploy a Postgres DB from Aria Automation
Login into the Aria Automation. Navigate to the Assembler. In the testing that I was doing prior to general availability, an additional configuration setting is required to show up the DSM interface in Aria Automation. Under Assembler > Infrastructure, modify the URL as shown below to access the configuration parameters. The parameter is enable.cci.DsmDatabase and it must be set to true. This may or may not be required at GA. I will revisit and change the post if it is no longer required. If you automatically see the DSM Database tile in the Namespace view below, then this step is not needed.
Now, as the user who have been granted permission to provision databases, navigate to the Service Broker. In our case, the user is amaury@rainpole.com. This user should now see an additional service available in the Supervisor Namespace called DSM Database, as shown below:
Click on the Open link on the DSM Database window to proceed with the creation of a PostgreSQL database.
Now click on the + Create button. Now you can begin to configure the database in exactly the same way that you could do so via the DSM appliance UI. Note that as you populate the configuration, the payload manifest which will be sent to the DSM Consumption Operator Supervisor Service is being built on the right-hand side. This can be very useful to capture for future deployment automation. When finished, click the create button.
And pretty soon the database should be provisioned on the infrastructure defined by the infrastructure policy in the DSM instance that you connected to.
And that concluded the fourth and final part of this series on posts on how to integrate the DSM Consumption Operator as a Supervisor Service with CCI & Aria Automation.
Summary
So that was quite a journey over the last number of posts. What we have done so far is as follows:
- In part 1, we deployed out Aria Automation v8.17 for CCI support
- In part 2, we look at how to install the CCI Supervisor Service in vSphere with Tanzu
- In part 3, we saw how to configure the CCI Supervisor Service to establish communication between the Supervisor and Aria Automation
- Finally, in part 4 above, we looked at how to install and configure the DSM Consumption Operator as a Supervisor Service to provision databases through Data Services Manager.
There are still some gaps to be addressed. For example, we only support PostgreSQL databases at present. However, there are plans to make this fully compatible with all features of the Data Services Manager that we have today in future updates. Thank you for reading this far. I hope you found the series useful and informative.