{{announcement.body}}
{{announcement.title}}

Steering the Wheel of Your App Deployment With Helm

DZone 's Guide to

Steering the Wheel of Your App Deployment With Helm

Take a look at Helm, a packaging manager compatible with Kubernetes for making deployments quicker and simpler for developers.

Free Resource

Introduction

A packaging manager is essential as the number of services increases complexity in an enterprise application development environments. Historically, enterprise app developers used to deploy on-premise applications with a simple copy and paste of the binaries, and then started writing basic scripts to deploy. This evolved into package managers like rpm, yum, pip and install anywhere, etc. 

Deployment infrastructure is changing from on-premise to cloud, and deployment environment have gone from OS to container engines or orchestration engines. This step demands the need for a new package manager which never existed before. 

Docker Engine and Kubernetes Orchestration platforms gaining popularity, HELM comes as de-facto standard for package management utility for Kuberenetes.

In this article, we will discuss the need of helm, helm introduction and how to make use of it for app deployment on container platforms.

Deployment Challenges in Enterprise Cloud-Native Apps

Cloud-native apps are built to have conceptual objectives mentioned below:

    1. Containerization

    2. Dynamically orchestrated

    3. Microservice-oriented

Architects and developers consistently make an effort to design and architect a microservice-based solution which can be deployed on-prem or on-cloud. Below is a list of challenges that are some of the common obstacles observed during the software development lifecycle.

  • Tight coupling or high dependency among (micro)services 

  • Service upgrade is non-autonomous, which complicates things when a particular service needs critical fix update.

  • Usage of multiple distinct technology stacks, causing increased maintenance cost in the long run.

  • High bandwidth and network latency expectation.

  • Design and control flow among many services are not test friendly. This makes testing much harder in comparison of monolithic applications because of lots of services.

  • Too much configurability kills the simplicity: The microservice application consists of many services which may need to be configured accordingly and each of them has to be configured, deployed and maintained.

  • Selection of IPC communication method: Microservices need to be written based on inter-process communication mechanism based on either messaging or RPC and error catching mechanism for catching partial failures.

These challenges cannot be resolved easily for the enterprise products that are in the industry from decades. Despite these challenges, making essential design changes can help you deploy your application on cloud-native platforms. Helm comes as a savior to do such heavy lifting of complex configuration and deployments. We will next see where Helm fits and how Helm can simplify the deployment.

Layer Over Layer Until We Reach Helm

Ever wondered about the extent to which we can add the virtualization/abstraction layers on top of each other? For the deployment of product we tested, CA Single Sign-On, the scenario is layered like below:

Image titleHelm is a package manager on top of Kubernetes orchestration. What Kubernetes can do in a couple of commands, Helm can do wonders using a single command.

Number of Services: Α Deployment Complexity

An increase in the number of services is directly proportional to efforts to deploy, test and maintain. Kubernetes or Helm accepts YAML as the scripting language. These YAML files are written in a very precise manner with spaces and tabs. Even if one space is wrongly used, the files will not be properly parsed and it becomes difficult to debug the entire file as it gets quite lengthy and confusing due to a large number of services.

Similarly, updating or upgrading any service has to be done very attentively as sometimes dependent services might get affected and may stop working or malfunction due to errors in dependency YAML files.

Customization and Complexity of YAML Specific to Each Deployment

Each deployment consists of its deployment structure which is written in YAML files. 

YAML files allow us tremendous flexibility to customize the configuration of our product. Just edit the required parameter in values.yaml and the rest will be taken care of by Helm. For such customizations, the template files which are referring to these values need not be touched. That’s the benefit of using centralized “values.yaml”.

Internal Functioning of Helm-Specific YAML Files

When Helm starts parsing, it first hits the values.yaml file. This values.yaml consists of the basic configuration of the application which is used across the files present in templates folder of that chart, which is used to deploy the application. Sometimes common properties are written inside the _helper.tpl file which consists of the variable name and its value which needs to be used across multiple charts. It is like defining a directive template.

Helm also supports sub-charts concept where each chart is a different service or sub-application and it is easier to configure every component/sub chart easily. Those sub-charts can be defined inside a chart folder and they have the same structure as that of their parent chart but different values in values.yaml.

Do Helm Like Yum

We all are aware of the simplicity yum has brought to managing (install, remove, upgrade etc) software packages. Imagine a tool which can do the same for the containerized applications developed by you. Helm is the way to go.

So, what yum is to an OS like RedHat, Helm is to Kubernetes.

Image title

Image title

Without Helm, Kubernetes deals in terms of individual resources/objects of an application which are deployments, services, secrets etc. But Helm deals with the whole application as one entity (chart) and does all the operations (deploy, delete, upgrade) on this single entity. The user doesn’t have to ensure that he is not missing running  kubectl create -f file.yaml   for any of the files. This way the user can focus on deploying applications rather than focusing on the environment.

Just do a helm install chart_directory –name release_name   and sit back to see everything getting deployed in a go.

Upgrades and Rollbacks

It's not an easy task to upgrade a deployed application. In Kubernetes, it becomes tedious to redeploy all the existing objects. It allows us to do this in two ways:

  1. Delete all the existing objects (deployments, pods, secrets etc) and redeploy using  kubectl create -f file.yaml.

  2. Do kubectl apply -f file.yaml for all the YAML files to bring the changes into effect.

Helm does it much in a simpler way. Again, just by a single command:  helm upgrade release_name chart_directory .

One can even rollback a release of an app to the previous release by virtue of only one command  helm rollback application revision_no .

Alternatives to Helm

There are couple of alternatives to helm present in today's date, which are:

    1. Draft
    2. Gitkube
    3. Ksonnet
    4. Metaparticle
    5. Skaffold

Under the Helm

Helm follows client-server communication model and it is written in 'Go' language.

Helm has two parts: Helm (client) & Tiller (server)

Helm client is a command line client for users which manages repositories and interacts with the Tiller to request for installations, upgrades, uninstallation etc.

Tiller runs inside of your Kubernetes cluster and manages releases (installations) of your charts. It interacts directly with the Kubernetes API server to install, upgrade, query and remove Kubernetes resources. It also stores the objects that represent releases.

Image title

Strict template & folder structure:

Image title

A Helm chart would typically consist of:

  • Description of the package (Chart.yaml)

  • One or more templates, which contain Kubernetes manifest files (deployment.yaml, service.yaml, pre-install-secrets.yaml etc)

  • Values.yaml file having values of all configuration variables shared by more than one deployments.

Conclusion

While we were writing Helm charts for large and true enterprise products like CA Single Sign-On, we realized that the development teams need to have a good understanding of the product design, deployment configuration options, external data sources, dependent libraries or third-party softwares, and temporary and permanent data location.

These Helm charts make the life of a developer very easy to deploy, migrate and upgrade an app on Kubernetes platforms.

We did observe the power Helm brings to the development team to make the deployment easy and simple. Helm is continuously making improvements to adapt to the needs of tomorrow.

We believe that Helm will be the de facto standard for Kubernetes deployments.

Topics:
helm ,cloud native deployment ,kubernetes ,cloud ,deployment

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}