Simplify continuous delivery with Tanzu Mission Control

2 July 2023

6 min read

Share
Author

Table of Contents

Introduction

Tanzu Mission Control (TMC) is a centralized management platform to create, operate and secure the managed Kubernetes cluster. TMC also provides a stable and simplified workflow to perform Continuous Delivery (CD) for cloud-native apps deployed on kubernetes cluster managed by TMC. Following GitOps, the entire DevSecOps pipeline can be built with handing over the CD responsibility to TMC. The application which is ready to deploy can connect it's config as kubernetes resources with kustomization or via Helm charts to TMC and configure the workflow. In this session, we would go through simple process to setup continuous delivery for a cloud-native application.

The workflow

  1. Configure Git repository with app deploy resources with kustomization configs in Tanzu Mission Control
  2. The continuous delivery extension in the managed Kubernetes cluster creates CRDs for Git repository and kustomization
  3. Flux controllers configured by TMC would sync Git repository to the Kubernetes cluster

More information about continuous delivery using Flux, visit https://fluxcd.io/docs/.

The entire workflow can be modelled as below :

tmc-cd-workflow.jpg

Accomplishments with CD workflow built with Tanzu Mission Control
Deployed application can be tracked for any change in app resources and the deployment in kubernetes is reconciled
This CD workflow can be used for building strong GitOps workflow for app delivery
Workload deployed via TMC can be configured for access control for group of users for secure and tracked production deployments.
Workload deployed can be configured with various policies configured as OPA policies

Brief about all the policy types for workloads can be found here.

Items to prepare for workflow

  1. Application image to deploy in Kubernetes
  2. Application deploy resources in Git repository.
  3. Kustomization resource as template and for manipulating app deploy resources.
  4. Kubernetes cluster configured to be managed by Tanzu Mission Control
cardIconNOTE

Application deploy resources can be maintained along side source code in folder or separate app deploy resource project. These resources can be managed by Operations team.

Helloappjava app which is used for this workflow is available at https://github.com/rajks24/helloappjava.git

The configuration

Add Git Repository

To start the process, need to add the App Git repository with the artifacts along with kustomization.

This option can be found as an add-on for the managed kubernetes cluster.

tmc-add-git-repo-1.jpg

We can configure the git repository with fields :

  • Repository Name
  • Repository URL ( with the app artifacts)
  • Repository credentials ( āš ļø It needs to be configured before adding git repository.)

Under the advanced options, we can configure :

  • Git Branch - When branch is given, then that branch from the git repository will be checked out. If no branch is given, the "master" branch will be used.
  • Git Tag - When a tag is given, that tag from the git repository will be checked out. If both tag and branch are given, tag overrides branch and the branch value will be ignored.
  • Semver - When semver is given, then the latest tag matching that semver will be checked out from the git repository. If semver is given, tag and branch will be ignored if they are populated.
  • Commit - When the commit is given, then that commit is checked out from the git repository
  • Sync Interval - (Default : 5 Min) This is the interval at which Tanzu Mission Control will attempt to reconcile changes in the repository to the cluster. A sync interval of 0 would result in no future syncs.
  • Git Implementation ( Default : GO_GIT, another option to choose - LIBGIT2)

tmc-add-git-repo-2.jpg

Git Credential

If the Git repository requires authentication, we need to register the credential before adding git repository. We can use the Git Credential to setup the app git repo with credential.

tmc-add-git-cred.jpg

Add Kustomization

Once the Git repository is added, we can go ahead and locate the app kubernetes artifacts along with kustomization in the git project. We can specify the specific Git Repo folder to sync the artifacts.

$ tree kubernetes
kubernetes
|-- deployment.yaml
|-- ingress.yaml
|-- kustomization.yaml
`-- service.yaml

My Kustomization resource is specified as below :

kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
- ingress.yaml
images:
- name: helloappjava
  newName: ghcr.io/rajks24/helloappjava
  newTag: 1.1.0
 

Also, can specify the Namespace to sync the resources.

šŸ’”

The operator get an option to select the target namespace which need to be used for deploying application along with Kustomization.

tmc-add-kustomize.jpg

Once the kustomization is added, the sync process starts and TMC starts pulling the resources from Git Repository and deploy to Kubernetes cluster using FluxCD. We can get the ReconciliationSucceeded status for process completion.

tmc-kustomize-reconciled.jpg

Verify deployed application

We can verify the deployment within the specified target namespace.

tmc-cd-app-deployed-1.jpg

Also, we can get the deployed resources in the workload section, to verify the state and the deployed yaml resources.

tmc-cd-app-deployed-2.jpg

We can verify that the deployed app is labeled for fluxCD.

metadata:
    labels:
        app: helloappjava
        kustomize.toolkit.fluxcd.io/name: helloappjava-kustomize
        kustomize.toolkit.fluxcd.io/namespace: tanzu-continuousdelivery-resources
    annotations:
        deployment.kubernetes.io/revision: '1'

TMC with help of FluxCD would track the app artifacts in Git repository for any change, and resync would be triggered for any git revision to reconcile the deployment in Kubernetes cluster.

Configure policies for workload

TMC is packed with various OPA policy templates which can be used to configure secure and managed delivery for workloads.

cardIconNext Step : configure policies for workloads
  • Security policy defines a set of conditions that a pod must run with in order to be accepted into the system

  • Image registry policies allow administrators to specify the image registries that developers can use in workspaces.

  • Network policies allow administrators to specify default network rules on workspaces.

  • Namespace quota policy defines a set of constraints that limit aggregate resource consumption per namespace.

  • Custom policies allow us to implement policies based on custom policy templates that we define to fit the needs of our organization's Kubernetes objectives.

  • Use a mutation policy to modify the properties of Kubernetes resources during admission.

Workspaces in TMC are used to manage access, policies and resources for group of workloads in same or across kubernetes cluster.

Summary

This workflow helps us to build a robust continuous delivery for production ready cloud-native workloads. I hope this blog would help users to understand and get desired outcomes.

šŸ™‚ Thank You!