One of the apps I like to use in the demos, is the Online Boutique microservices app provided by Google Cloud.
Online Boutique is a cloud-first microservices demo application. Online Boutique consists of an 11-tier microservices application. The application is a web-based e-commerce app where users can browse items, add them to the cart, and purchase them.
Google uses this application to demonstrate the use of technologies like Kubernetes, GKE, Istio, Stackdriver, and gRPC. This application works on any Kubernetes cluster, like Google Kubernetes Engine (GKE). It’s easy to deploy with little to no configuration
The app runs on GKE, but can also be deployed to a TKG cluster (or any other Kubernetes flavor). You can just directly clone the app, or fork it first of you want to make some changes. A simple
kubectl apply -f ./release/kubernetes-manifests.yaml
will deploy the app to your Kubernetes cluster. Then execute
kubectl get service frontend-external | awk '{print $4}'
to retrieve the LB address of your application.
About Kustomize and GitOps
The repository of this demo app contains a Kustomize folder, which allows you to deploy variations of the application using Kustomize. Kustomize is a Kubernetes configuration management tool that allows you to customize your app without duplicating the entire app. Kustomize is part of kubectl, you can deploy an app using a Kustomize configuration using
kubectl apply -k
Combining Kustomize with Git and FluxCD give you some interesting options; it allows you to deploy an app to a Kubernetes cluster while keeping its state (based on the repository on Git) consistent. This is exactly what Tanzu Mission Control brings you, and in that way provides you a GitOps way of deploying and updating your app (in this case the Online Boutique microservices app).
The way this works is explained in the following diagram, coming from the TMC documentation:
Our Online Boutique microservices app (or actually the definition of it) lives in a Git Repository. My Kubernetes cluster is running FluxCD that is monitoring the Git repository for update. After an update have been published (or a new repository got added), Kustomize will take care of deploying/updating the application.
Initial setup
Setting this up is a pretty straight forward 4 step process:
- Enable Continuous Delivery on a cluster.
- Add a repository credential.
- Add a Git repository.
- Add a Kustomization.
All these actions are performed in Tanzu Mission Control (TMC), of course you first have to create a cluster group and add your cluster to Tanzu Mission Control.
Enable Continuous Delivery on a cluster or cluster group
You can use to enable Continuous Delivery on a cluster or a cluster group. When you configure Continuous Delivery on the cluster group level, the configuration will deployed to all Kubernetes clusters that are part of the cluster group.
Go to add-ons, choose Installed Kustomizations and select Enable Continuous Delivery.
After a couple of minutes your cluster(s) will show status Ready, that means you can use Continuous Delivery. Four namespaces are added to your cluster: tanzu-continuousdelivery-resources, tanzu-fluxcd-packageinstalls, tanzu-kustomize-controller and tanzu-source-controller.
Add a repository credential
The next step is to add a repository credential, if your Git repository requires this. This is not required for public repositories.
Both username/password and SSH keys are supported. Read more about creating an SSH key here, and how to add the public SSH key to GitHub.
Add a Git Repository
Now it’s time to add a Git repository to your TMC environment. In this example I’ve created a copy of the original Microservices app to my own GitHub repository. Choose add-ons -> Git repositories and add the Git Reposity.
If required, link the repository credentials created in the previous step to the Git repository.
Add a Kustomization and deploy the app
Now it’s finally time to add the Kustomization to your configuration/cluster, this will trigger the initial installation of your app. You have to configure the location of the kustomization.yaml file so the app can be deployed. In this example the location of the kustomization.yaml is the “kustomize” folder, so just enter “kustomize” here.
You can optionally add the namespace you want to deploy the app to, so you don’t have to specify it in the kustomization. Note that the namespace should be pre-provisioned. Also important: the integration is looking at the main branch in your Git repository.
Kustomize the app
Now the initial version of the app is deployed to your Kubernetes cluster. Use
kubectl get service frontend-external | awk '{print $4}'
to learn the load balancing address where your app is available. Execute this command in the context of the namespace where you’ve installed the app.
Now the cool stuff is, that it’s really easy to change the app. Let’s say we want to update the branding of our shop. There’s a predefined component included, that we just have to enable/configure on the Git repository. TMC’s GitOps/CD capability will then automatically reconcile and update the branding of your app.
Update your kustomization.yaml so it shows:
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: - components/cymbal-branding
In a few seconds your app will reconcile, first you will see “progressing”
and then the “ReconcilliationSucceeded” will follow.
and the new branding is now displayed on the main page.
There are various other Kustomizations included that you can test. Some of these Kustomizations requires the app running on GKE, which is not the case in this example. The “Create Kubernetes Service Accounts” Kustomization is easy to deploy and doesn’t require additional configuration steps. The kustomization.yaml now includes:
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: - components/cymbal-branding - components/service-accounts
It will take a while before the service accounts are created:
k get serviceaccount NAME SECRETS AGE adservice 1 15m cartservice 1 15m checkoutservice 1 15m currencyservice 1 15m default 1 14d emailservice 1 15m frontend 1 15m loadgenerator 1 15m paymentservice 1 15m productcatalogservice 1 15m recommendationservice 1 15m shippingservice 1 15m
To conclude
I hope this gives some ideas about how the continuous delivery/GitOps capability of TMC works. The real power is of course also in configuring this feature on a series of clusters, that are part of a cluster group. In such a scenario you are able to deploy and kustomize the same app to different clusters within seconds/minutes.
I hope this was helpful, feel free to leave a comment below!
