Continuous Delivery Options

Continuous Delivery is a critical pillar for DevOps. Implementing a reliable and secure delivery pipeline can be challenging especially when dealing with multiple clouds, multiple development teams and numerous applications.

Nirmata provides you with a secure single pane of glass to deploy, monitor and manage your Kubernetes applications in a multi-cluster and multi-cloud environment. In particular, it offers you several options to implement your Continuous Delivery pipeline:

• GitOps workflow (pull model)
• Nirmata Jenkins plugin (push model)
• Nirmata API calls
• Integration with third-party vendors, Circle CI for instance

In this blog, we will address in details how to configure your Continuous Delivery pipeline using Nirmata and Kubernetes with a GitOps approach.

GitOps Workflow

The idea behind GitOps is straight-forward: You want to:

1. use Git as the single source of truth for your workload deployments and
2. track every change made to your running workloads in Git.

A GitOps workflow can also implies that changes are propagated to your running workloads using a pull model. A component such as Nirmata is located between your Git repositories and your running workloads. This component is in charge of detecting new commits in the Git repositories and pulling them into the Kubernetes clusters.

In the picture above, we present an example of an end-to-end GitOps workflow using Jenkins, Docker, Kustomize, Nirmata and Kubernetes.

Steps 1,2,3 & 4:

All DevOps practitioners should be familiar with these steps: A developer makes a change to the source code in a Git repositiory. Jenkins detects the change and builds a new Docker image with a new tag. The new image is stored in a central repository. There is nothing specific to a GitOps workflow in these steps.

Step 5, 6 & 7:

The goal of these steps is to updates the YAML definitions of your workloads with the new Docker tag generated previously. Jenkins clones the git repository containing the YAML files and it changes the tag of the modified workload. Then Jenkins commits the change in Git and it pushes it into the remote Git repository. You can optionally use Kustomize in these steps.

Kustomize provides a simple and elegant way to manage YAML variations between your deployment environments: dev, staging, production. In each environment, you may want to use different configuration values (ConfigMap and environment variables), passwords and certificates (Secrets, Ingress) and replicas. Kustomize will help you do exactly that. How you can best use Kustomize and Jenkins to manages your various deployment environments, is a topic for its own separate blog post.

Steps 8, 9 & 10

These steps are specific to a GitOps workflow. Nirmata has been configured to listen to the Git repository changes. When the new tag of a workload is committed in the Git repository, Nirmata pulls the YAML files and identifies the corresponding Cloud, Cluster and Namespace where the change must be applied. Once Kubernetes is updated with the new workload tag, the new image is pulled from the Docker repository and the workload is updated.

Nirmata Configuration

Now, let’s see how Nirmata was configured. The user must first create an environment and associate this environment to one cluster. In our case we want to create a staging environment. Then the user must provide the Git credentials:

 .     

The user is now ready to deploy the application in the environment. In this example we use the Guestbook application:

The important parameters to consider are the followings:

Git Upstream
When deploying an application, users can specify where the YAML definitions come from. There are two choices available today: Catalog and Git. In our case we want the application to be backed by a Git repository so we select the Git option.

Git Credentials
We can select here the credentials we have previously configured.

Repository
Here you must provide the URL of you git repository repository. You can use a private Git server, BitBucket, GitHub, etc.

Branch
As soon as you enter the URL of the repository, Nirmata will try to connect to your server and retrieve the list of branches available. Using the drop-down you can select the branch you want to work with. If your server not reachable or your credentials are not valid, then an error is displayed.

Directory List & Include List
The next two parameters are optional: Directory list and include list. By default, if you do not specify any values for these fields, Nirmata will look recursively in all the directories of your repository and select all the files ending with an extension *.yml or *.yaml. If you want to select specific files or directories then you can define it here. In this example we only want to use the file named guestbook-staging.yaml located in the root directory of the repository.

Once you have entered this information, Nirmata will clone your repository and find all the YAML files corresponding to your settings. At this point, Nirmata can deploy your application in the Kubernetes cluster.

Nirmata Change Management

Nirmata provides powerful features to help you track and manage changes made to your application. First, you can check the last commit that was pulled into your cluster. Just click on the Git icon of your application:

The user can see the last commit ID, the name of the committer and the commit message.

Whenever one or multiple new commits are detected, Nirmata pulls the changes. Depending on the update policy configured for the environment, Nirmata will either apply the changes immediately or it will display a list of pending changes. The user can then review the changes and decide when they should be applied:

 

In the previous example, we performed three modifications to the frontend Deployment: The container request was decreased from 500 Mi to 100 Mi, the container limit was decreased from 500 Mi to 400 Mi and the tag of the frontend image was changed from v4 to v68. After reviewing the changes, the user can decide to accept or to reject the pending changes.

The use can use the system task panel to see the history of all the modifications made to the application:

When a workload goes into a degraded or a failed state, the user can go the events panel, find the details of the error and then look at the system tasks to find the root cause of the problem. In this example an incorrect Docker image name was checked in the Git repository.

 

Trying Nirmata

Trying Nirmata is easy and it is free to try! Just sign-up online at https://nirmata.io.  We would love to hear your thoughts on Nirmata and to discuss your Continuous Delivery needs.