Deploy any Application using App Launchpad on Cloud Director Service:

App Launchpad is VMware Cloud Director’s go-to service for Application-as-a-Service platform for the customers. App launchpad enables providers to create and manage application catalog, various sizing templates, default application deployment configurations, and more. ALP provider admin can also manage application versions from bitnami/cloud marketplace based on customer requests.  When App Launchpad is enabled for the customer organization, and its users, the users can access all provider published applications from VMware Cloud Directors tenant portal. The application deployment proccess is simplified by App lauchpad in a way that, customer user can deploy application of their choice with 1-click, without worrying about infrastructure configurations like network, storage, VM size, etc.

This Feature Friday Episode described the App launchpad 2.0 updates and capabilities in detail. To summarize, ALP 2.0 version offers the following:

– Provider can connect to the Cloud marketplace directly from VCD to select VM-based and container-based applications.

– It is now possible to deploy a container in the  CSE deployed K8s cluster.

– Introduced Public API support to support provider and customer workflows.

– Improved Catalog management.

– New Application Categories.

In this blog post, we saw that CSE 3.0.1 offers Kubernetes-as-Service on Cloud Director service. With ALP 2.0 update, providers can use App Launchpad on Cloud Director service to deploy VM and container-based applications. This blog post focuses on App launchpad extension on Cloud director service to deploy containers on K8s Clusters. We have assumed that the K8s clusters are deployed using CSE in the customer organization.

We will use the following reference topology to describe the steps:

Figure 1: App Launchpad, CSE server, Customer Organization topology in a Cloud Director service, connected to VMC on AWS/SDDC.

The Multitenancy on CDS white paper is available here. We can refer to the white paper to configure NAT rules and Firewall rules for ALP Server and is outside of the scope of this post.

There are three main steps for provider administrator:

• Install ALP service
• Allow ALP service to connect to Provider’s external network and Internet
• Publish CSE rights bundles to ALP User role
• Associate customer’s K8s cluster IP address within ALP server

Install ALP Service:

ALP service is installed on any Linux-based appliance(I have used Centos to describe the steps in this post). The rpm distribution is available for free to be downloaded from official VMware download site. We can install and configure the ALP server on Provider’s ‘System VDC’ resource pool on SDDC and connect ALP server to Compute Gateway(CGW)-backed network using vCenter UI. The Figure1 describes the topology, placement of App Launchpad server, CSE server, Customer organization, and more. Provider administrator may require Internet access to the ALP server machine to install required packages.

The commands to install ALP service are:

Allow ALP service to connect to Provider’s external network and Internet

We must allow communication from ALP Servers with Customer deployed K8s Clusters. By design, Customer K8s clusters deployed through CSE are connect to Routed Org VDC networks. Customers create NAT rules to map routed networks to external network IP ranges to provide inbound internet connectivity. Figures 2 shows example Internet NAT rule for ALP server mapping CGW network with ALP server’s Public IP address. Firgure 3 shows example Gateway firewall rule to Allow access from ALP server to External networks.

Figure 2: Example Internet NAT rule to allow Public IP: CGW network IP of App Launchpad serverFigure 3 Allow ALP Server to access K8s clusters using External Network IP addresses

Publish CSE rights bundles to ALP User role

This step is required when CSE service is installed after ALP extension is configured by the provider on CDs. When CSE service is configured prior to ALP, the ALP service role assumes TKG related capabilities shown in the screenshot below.

This step will allow the ALP service role and user to access the customer’s Kubernetes cluster to deploy the container. We can perform this action by logging into CDs provider portal and editing ALP user role created from 1st step in this blog post.

Figure 4: Publish rights bundle to ALP user role.

After this step ALP service needs to be restarted. This requires logging into ALP server using public IP address and using command “sudo systemctl start/status alp”.

Associate customer’s K8s cluster IP address within ALP server

This step ensures correct mapping of K8s clusters association with External network IP address for ALP Server.  You may ask, why do we need to maintain this mapping?

K8s clusters deployed using CSE extension uses routed Org VDC networks. For K8s inbound and outbound connection, NAT rules are also required (Refer the Multi-tenancy networking white-paper). ALP server has access to the customer’s External network IP address allocated to K8s server to deploy a container. (From the step-2)

And the ALP service is set for the customers to deploy a container based Application!

Figure 5: The container-based application is ready to be launched from Customer ALP UI

The blogpost covered procedure to configure ALP service on Cloud Director service in detail. With this, Application-as-a-Service by ALP is now available on Cloud Director Service.

Further Reading: