Consume VMware Tanzu Application Catalog Helm Charts using Kubeapps

This section explains how to set up the VMware Tanzu Application Catalog (Tanzu Application Catalog) as a package repository in Kubeapps and how to deploy a WordPress Helm chart from this source. In addition, it describes how to use an existing MariaDB Galera cluster as an external database in your WordPress deployment to run a production-ready blog.

To simplify application deployment and management on Kubernetes, Kubeapps provides a web-based dashboard to deploy, manage, and upgrade packaged applications on a Kubernetes cluster. It supports multiple packaging formats, such as Helm Charts, Helm Charts via FluxCD, Carvel Packages and Operators.

Kubeapps is the best option for enterprise development teams since Kubeapps uses the cluster’s existing configured RBAC rules. This allows operators and cluster admins to control which users can access and manage applications. Kubeapps can thus be used as the central place for managing all enterprise application deployments with total confidence.

In addition, you can configure Kubeapps to use your private application repository as its source. This feature gives you the option of extending your catalog with your charts located in a private repository such as ChartMuseum, Harbor, Artifactory, or even use your customized Helm chart catalog directly from the Tanzu Application Catalog.

Kubeapps can be easily configured to automatically sync Helm charts from the Tanzu Application Catalog. Users will benefit from a browser-based user interface to customize, upgrade and rollback their deployments using the latest, most secure and up-to-date Helm charts from the Tanzu Application Catalog.

What to do first

Ensure:

You have access to the Tanzu Application Catalog Demo environment and to a pre-built or custom catalog. If you are a VMware employee, you can request access internally. For customer access, contact your VMware sales representative.
You have a Kubernetes cluster. For more information, see Getting Started with Kubernetes guides.
You have Helm 3 installed.
You have Kubeapps installed in your cluster and you have the proper RBAC set up to perform the actions. For more information, see access control in Kubeapps.
(Optional) You have deployed MariaDB Galera from the Tanzu Application Catalog and running on the same cluster as Kubeapps.

Here WordPress is used as an example, but you can follow the instructions shown in this article to deploy on your cluster any other Helm chart from the Tanzu Application Catalog using the Kubeapps UI.

To consume Tanzu Application Catalog Helm Charts using Kubeapps, follow the steps as explained in the sections below:

Add the Tanzu Application Catalog as a package repository
Deploy WordPress from Kubeapps
Access WordPress using Ingress

Add the Tanzu Application Catalog as a package repository

The first step is to create a package repository in Kubeapps pointing to the Tanzu Application Catalog repository. Follow the instructions below:

Log in to Kubeapps.
Select the namespace by clicking on the context selector dropdown on the top right. Select the namespace you want, for instance, “my-namespace” or “default”, and click on “Change Context”.
In the “Administration” menu on the right panel, select the “Package Repositories” option.
Click on the “Add Package Repository” button and a form will be displayed.
1. Inside the “Basic Information” tab:
  1. Enter a descriptive “Name”, for instance, vac.
  2. Enter a repository “URL” as follows:
    1. If you want to add the entire catalog to Kubeapps, use the Tanzu Application Catalog URL you already have with your subscription. For more information, contact your VMware representative. Note that the URL used in the screenshots is just a placeholder, not a real one.
    2. If you just want to add a specific chart to Kubeapps, add the chart URL you will find under the “Chart Information” section in the Tanzu Application Catalog:
    1. Select Helm Charts as the “Packaging Format”.
    2. Select Namespaced as the “Scope”, so that the repository becomes available just in the selected namespace.
    3. Select OCI Registry as the “Package Storage Type”.
2. Inside the “Authentication” tab:
  1. Select Basic Auth for the “Repository Authorization”.
  2. In the “Username” and “Password” fields, enter the generated credentials for the application repository in the Tanzu Application Catalog. If unsure, contact your VMware representative.
  3. Use None (Public) for the “Container Registry Credentials”.
  4. Click on the “Install Repository” button.
The new repository is now created and being synchronized. This process may take a few minutes. It is normal to see an empty catalog while all the packages are being synced.

To check the progress of the synchronization task, execute:
```
# Replace "vac" with the repository name you chose, and "my-namespace" with the namespace you used

kubectl logs -n my-namespace -l apprepositories.kubeapps.com/repo-name=vac
```
In the Catalog tab, you can find your packages ready to be used.

Deploy WordPress from Kubeapps

Once you have added the Tanzu Application Catalog as a new repository in Kubeapps, all the packages in the catalog will become available for deployment through Kubeapps. This guide uses WordPress as an example, but you can deploy any other chart that you have in your catalog. Follow the instructions below:

Click on the “Catalog” tab in the navigation bar and search for WordPress.

Two charts will be displayed, one with the “bitnami” tag and another with the “vac” (or the name you gave to the repository) tag. Select the latter.

On the resulting page, you will find information about the WordPress Helm chart. You will also find the version of the chart that exists in the Tanzu Application Catalog:

Tip If you navigate to the Tanzu Application Catalog and search for “WordPress”, you will see that the version of the chart available in your catalog matches the one shown in Kubeapps. For more information on charts and container releases in the Tanzu Application Catalog, see Releases.
Click “Deploy” to deploy the chart.

This opens a page where you can configure your WordPress deployment. You can use either the “visual editor” or the “YAML editor” tab to customize your deployment as you want: give your chart a name, change the version you want to deploy, set the WordPress admin password, etc. You can tweak up any Helm values available in the chart.

Note
This example uses the “default” namespace, but it should match the one in which you installed the repository. For instance, “my-namespace”.
In this example, Ingress will be enabled. If you have an Ingress Controller (for example, Ingress-NGINX) running in your cluster, you can enable the custom hostname in order to use a hostname rather than just a public IP. Also, if cert-manager is available in the cluster, you can also enable it along with the TLS option in order to automatically generate a certificate and use HTTPS.

To do so, navigate to the “ingress” section (or search for “ingress” in the box) and perform the following steps:
- Enable “ingress/enabled”.
- In “ingress/hostname”, enter your custom hostname.
- Enable “ingress/tls”.
You can check that all these values have been correctly added to the values.yaml chart in the “YAML editor” tab:
Besides, in this example, a side-car Prometheus exporter will be created. To do so, navigate to the “metrics” section (or search for “metrics” in the box) and perform the following step:
- Enable “metrics/enabled”.
Finally, click on the “Deploy” button to start the deployment. Once submitted, you will be redirected to a page that describes the state of your deployment. The status will be “Deploying” until WordPress is up and running.

Access WordPress using Ingress

Once the chart is deployed, you can see all the deployment details, including the URLs to access the application. In this case, you will see two URLs:

Service LoadBalancer: By default, WordPress creates a Service with LoadBalancer type to provide an externally accessible URL for its web interface.
Ingress: Corresponds to the hostname you set when enabling Ingress. This URL redirects you to a WordPress deployment which is already secured by cert-manager.

URLs to access Kubeapps

In the deployment details page, you can also view the secrets assigned to both the database and the application under the “Application Secrets” or the “Application Resources” sections. Additionally, you can just navigate through the installation values.

Application and database credentials

To access WordPress, click the Ingress URL. This opens a new tab in your browser with your WordPress blog. You will see the lock in the navigation bar, this means that your deployment is secure, using HTTPS with a valid certificate:

WordPress running with HTTPS

Appendix: Deploy a production-ready WordPress using an external database from Kubeapps

If you need a deployment able to respond in a high-demand environment and ensure failover and high availability, then you can configure a WordPress installation using an existing MariaDB Galera cluster as an external database.

The following example uses a already existing MariaDB Galera deployment running in the Kubeapps cluster and focuses on how to configure a new WordPress deployment using the Kubeapps UI.

MariaDB Galera already installed

Navigate to the application details to find some pieces of information that you will require in the upcoming steps, namely:

Service name, in this example, “my-mariadb-galera”.
Database name, in this example, “my_database”.
Database username, in this example, “my-username”
Database password, in this example, “my-password”.

MariaDB Galera details

To deploy a WordPress production-ready using an external MariaDB Galera database, follow these steps:

Click on the “Catalog” tab in the navigation bar and search for WordPress.

Two charts will be displayed, one with the “bitnami” tag and another with the “vac” (or the name you gave to the repository) tag. Select the latter.
Click “Deploy” to deploy the chart. This will take you to a page where you can configure your WordPress deployment.
Enter a name for this deployment.
First, to prevent the built-in DB to be spun up, navigate to the “mariadb” section (or search for “mariadb” in the box) and perform the following step:
- Deactivate “mariadb/enabled”.
Next, we need to provide the configuration for the external database we have. Navigate to the “externalDatabase” section (or search for “externalDatabase” in the box) and perform the following steps:
- In “externalDatabase/host” enter the MariaDB Galera service name we found in the previous steps. In this example, “my-mariadb-galera”.
  
  Note
  Remember to select the same namespace where the MariaDB Galera cluster is running. In case you want to deploy WordPress in a different namespace, you must add it at the end of the database host as follows: DB-HOST.NAMESPACE. Being DB-HOST a placeholder of the service for the external database and NAMESPACE a placeholder for the namespace in which the database is running.
- In “externalDatabase/user” enter the custom username you set when deploying the MariaDB Galera cluster. In this example, “my-username”.
- In “externalDatabase/password” enter the custom password you set when deploying the MariaDB Galera cluster. In this example, “my-password”.
- In “externalDatabase/database” enter the custom database name you set when deploying the MariaDB Galera cluster. In this example, “my_database”.
- Keep the default “externalDatabase/port” value, unless you have changed it.
Once you have configured the external database values, you can configure other parameters such as enabling Ingress, Metrics, cert-manager or TLS as previously described in the deploying WordPress from Kubeapps section.
Click “Deploy” to start the deployment of the chart. After several minutes, your deployment will be ready and you will be able to access WordPress using Ingress (if you enabled it) or the Service LoadBalancer URL.

WordPress installed