Over the last few years, VCD has evolved as a true developer ready cloud. To start with, VCD enabled Service Providers to offer multi-tenant/multi-cluster Kubernetes as-a-Service through Container Service Extension and lately enabled integration with Tanzu Mission Control to simplify the Kubernetes management and visibility across environments through a single pane of glass.
Software as a Service (SaaS) has emerged as a game-changer, offering a flexible and scalable approach to software delivery that aligns perfectly with the demands of modern businesses. To cater to this need, VCD integrates with the App Launchpad service that offers a self-service portal to tenants to deploy and manage their applications easily. It allows users to deploy and manage applications on top of the infrastructure provisioned through the VCD portal and provides a user-friendly interface for application provisioning.
The main challenge with App Launchpad was the need for administrators to handle catalog items individually, resulting in increased overhead.… Read More
OpenID Connect (OIDC) is an identity authentication protocol that extends open authorization (OAuth) 2.0 to standardize the process for authenticating and authorizing users. The OAuth 2.0 protocol enables a third-party application (called a client) to access resources from a resource server (such as an API) on behalf of a user (referred to as a resource owner). The user provides the client with a limited access token, which it can use to request resources from the resource server.
The OAuth 2.0 protocol provides security through scoped access tokens, and OIDC provides user authentication and single sign-on (SSO) functionality. The access token issued by an authorization server verifies the identity and consent of the user.
VMware Cloud Director can be integrated with an external OIDC provider to import users/groups created in the upstream IDP. The Service Provider imports users/groups in VCD and associates them with appropriate roles.… Read More
Starting with VCD 10.2 and App Launchpad 2.0.0.1, it is possible to deploy App Launchpad using MQTT for communication with VCD.
VCD 10.5 introduced a new feature called Content Hub as a replacement for App Launchpad. Service providers running VCD 10.5.x are encouraged to provide container/vm applications to tenants by integrating Content Hub with VMware MarketPlace and Helm repositories.
In this post, I will demonstrate how you can delete MQTT enabled App Launchpad extension from VCD.
Step 1: List Installed Extensions
1
2
3
4
5
6
7
Method:GET
URL:https://{{vcd_host}}/cloudapi/extensions/api
Authorization:Bearer(JWT Token)
Headers:Accept:application/json;version=38.0
The GET call returns a json in response listing all installed extensions and its ID. From the extensions list filter the ID of the App Launchpad extension.… Read More
App Launchpad is a VMware Cloud Director service extension that service providers can use to create and publish catalogs of deployment-ready applications. Tenant users can then deploy the applications with a single click.
App Launchpad supports applications from the Bitnami applications catalog that are available in the VMware Cloud Marketplace.
You can create catalogs of your custom, in-house applications and configure App Launchpad to work with these catalogs.
The older versions of the App Launchpad (<=2.0), use AMQP to communicate with VCD. Starting with App Launchpad v2.0.0.1, the MQTT protocol is also supported.
If you are using AMQP for the App Launchpad and running version > 2.0.0, you can reconfigure App Launchpad to use the MQTT protocol.
You have to first delete AMQP enabled App Launchpad before you can reconfigure it to use MQTT.
The older versions of VMware Cloud Director used AMQP protocol to exchange messages (such as system notifications or any other update) with another VCD cell. Starting with VCD 10.1, MQTT replaced AMQP. To learn more about how VCD used MQTT, see product documentation.
If you have an environment that still uses AMQP (e.g., VCD upgraded from version <=10.1) and wants to replace it with MQTT, you must first delete the AMQP broker settings from VCD. Unfortunately, it is not currently feasible to delete the settings from the GUI and must be done through APIs.
In the VCD GUI, you only see 2 options for the AMQP broker: Edit settings and Test AMQP config. There is no delete option.
In this post, I will show what APIs you need to delete AMQP broker settings.
Step 1: Get AMQP Broker Configuration
Note: The below APIs are applicable for VCD 10.5.1. If you are running an older version of VCD, check the supported API versions that you can use.… Read More
Welcome to yet another troubleshooting post for tmc self-managed operation in VCD. In the last post, I discussed the tmc self-managed deployment issue and how I fixed it. In this post, I will discuss another issue that I encountered with the solution.
After successfully deploying TMC Self-Managed, you must publish the solution to tenants so that they can attach their TKG clusters to TMC. When the publishing operation is performed, the TMC Self-Managed Add-On solution creates a temporary VM known as the solution agent vm, which is subsequently destroyed once the task is complete.
In my lab, the publishing task was completed for a couple of tenants and later when I tried publishing it to another tenant, the task got stuck (VCD was acting cranky at that time).
This behavior is encountered when the solutions process in the VCD cell gets killed or there is network interruption between the cell and the VCD public address during the operation execution.
My previous blog post discussed the VCD Extension for Tanzu Mission Control and covered the end-to-end deployment steps. In this post, I will cover how to troubleshoot a stuck TMC self-managed deployment in VCD.
I was deploying TMC self-managed in a new environment, and during configuration, I made a mistake by passing an incorrect value for the DNS zone, leading to a stuck deployment that did not terminate automatically. I waited for a couple of hours for the task to fail, but the task kept on running, thus preventing me from installing it with the correct configuration.
The deployment was stalled in the Creating phase and did not fail.
On checking the pods in the tmc-local namespace, a lot of them were stuck in either ‘CreateContainerConfigError” or “CrashLoopBackOff” states.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
root@jumpbox:~# kubectl get po -n tmc-local | grep CreateContainerConfigError
In VCD, when I checked the failed task ‘Execute global ‘post-create’ action,” I found the installer was complaining that the tmc package installation reconciliation failed.… Read More
