Find previous blogs in Julio’s DevOps series.
Moving forward in our DevOps series, I would like to explore with you some specific tools and processes that help with automation for your software. If you are involved in the lifecycle of an application I am pretty sure you will be interested in anything that makes your work-life easier.
Microservices Package Manager Makes It Easier to Deploy Complex Kubernetes Applications
As you may have already noticed while working with microservices, applications can get really complex. In terms of app architecture, you will very soon find yourself dealing with multiple containers/pods, that need to be started/stopped with any new deployment in different environments (testing, staging, QA, production). Wouldn’t it be nice to have a tool that packages all required microservices, and start/stop them as per the required dependencies, in an easy way?
Helm is a package manager for Kubernetes. It helps defining, installing and upgrading complex Kubernetes (aka k8s) applications. Instead of applying individual manifests, you can package all of them and deploy your application easily. That package is called a chart, and its actual deployment a release.
It offers amazing templating capabilities as well, but for this post we will only use its help with application packaging.
Helm has two components: client (local agent that communicates with the server) and server (called tiller, that runs inside the k8s cluster). Tiller is the one that communicates with k8s API server to deploy the required resources in the k8s cluster.
First thing you will need to do is to install the Helm client in your laptop.
As a Mac user you can install the Helm client with:
brew install kubernetes-helm
For our post today we will use a managed k8s cluster deployed on Google Kubernetes Engine (GKE), like the one we used in a previous post.
Please make sure your kubectl context points to the GKE cluster, and all your nodes are ready:
kubectl config get-contexts kubectl get nodes
Use your helm client to deploy the tiller server in your k8s cluster with a simple command:
helm init
List all available stable charts (ie. packages):
helm search
Or look for a specific one, like for example WordPress:
helm search wordpress
Let’s use WordPress as an example. As you probably know WordPress is an open-source web/blog platform. It is composed by a web server front-end and a database. If you wanted to deploy it manually you would at least need to manage and configure for interoperability two containers: one webserver and one database.
Helm helps you by providing a chart where everything is configured for you, so you can easily deploy the whole application with:
helm install --name my-wp stable/wordpress
You will see Helm returns some indications on how to access your WordPress deployment (URL, username and password).
Make sure both of your pods (wordpress and mariadb) are running and ready 1/1.
kubectl get pods
And wait until your new WP LoadBalancer service gets an external IP address.
kubectl get services
Once the external IP address is populated, you can use it to access your new WordPress deployment from your browser. Easy, huh?
Helm also allows you to create your own charts, so why don’t we create one for myhero? That way we will not have to deal with all individual manifests, but rather easily install the complete application with a single command.
Helm is based on templating, so we could create some templates with parameters, and instantiate them with values for each one of the services and deployments. But as long as this is not a Helm tutorial we will not use templates, and do it the easy way.
( Please note, if you have not followed my previous posts you will need to clone the devops repo now, with: git clone https://github.com/juliogomez/devops.git )
Go into your devops directory and create a new helm directory there:
cd devops mkdir helm
There please create a new helm chart for your myhero application:
helm create myhero
Go into the templates directory and delete all templates in there (we will not need them), and just copy all myhero manifests there:
cd myhero/templates rm * cp ../../k8s/gce/*.yml .
Now go out of that directory, create a new myhero helm chart, and you will get a myhero-0.1.0.tgz file:
cd ../.. helm package myhero ls
With that simple process you can now deploy your myhero application with a single command!
helm install --name helm-myhero myhero-0.1.0.tgz
Watch pods, services and ingress being created:
kubectl get pods kubectl get services kubectl get ingress
Please note that, as discussed in a previous post, if you want to access your app from Internet, you will need to make sure that name resolution (ie. DDNS) for the required 3 hostnames (spark-myhero, ui-myhero, and api-myhero) is updated with new the public IP address you have in your Ingress now.
Once you are finished testing you may easily delete your myhero application, again with just one simple command:
helm delete --purge helm-myhero
Congratulations! Now you know how to package your software, so it can be easily deployed in other environments by operations or other developers.
It is about time to move forward with how to automate the lifecycle of our software… See you in my next post, where we will discuss continuous integration, delivery and deployment. Stay tuned!
Any questions or comments please let me know in the comments section below, Twitter or LinkedIn.
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel
CONNECT WITH US