How to automatically deploy Helm charts to a Kubernetes cluster
Helm charts lifecycle management is a manual task. Helmsman allows you to automate your Helm charts lifecycle management using declarative configuration files.
Helm packages Kubernetes applications as reusable, customizable and shareable packages called “charts”. Helmsman adds a layer of abstraction around Helm and allows users to declaratively define a desired state of their Helm charts in a Kubernetes cluster.
While working on deploying Atlassian products in a Kubernetes cluster for a customer, we started by creating Kubernetes manifest files for the needed Kubernetes objects. We needed to automate the deployment of these objects in the cluster everytime we push changes in our git repo. We came up with a custom script in our CI pipeline to do this for us. The operations we wanted to support included: creating, deleting, upgrading and moving Kubernetes objects to different namespaces. As we progressed in the project, it quickly turned out that the script became complex and difficult to maintain. It needed to be updated every time we added a new Kubernetes object. We started using Helm as it helped us group multiple Kubernetes objects into one unit; a “chart”. Then the CI script got a bit simpler, but still needed to be updated regularly with new charts. And what if we need to replicate this setup for another customer? We will need to replicate and customize the CI script.
We needed a more dynamic and less interactive way of doing this. Then, came the idea of defining a “desired state”, -describing what charts and where we want them to exist in the cluster- and a tool that is smart enough to make sure this state is achieved. Something like infrastructure as code, but for Helm charts (Kubernetes apps). When we change the desired state, the tool can understand what changes we need and make them happen for us. This way, we only need to maintain our desired state and let the tool handle the logic of how it’s implemented. We called this tool “Helmsman” since it works as autopilot for your Kubernetes cluster.
Helmsman gets its directions to navigate from a declarative file called Desired State File (DSF) maintained by the user (Kubernetes admin) and is usually version controlled. DSFs follow a specification which allows user to define how to connect to a Kubernetes cluster, what namespaces to use/create, what Helm repos to use for finding charts, and what instances (aka releases) of the chart to be installed/deleted/rolled back/upgraded and with what input parameters.
Helmsman interprets your wishes from the DSF and compares it to what’s running in the designated cluster. It is smart enough to figure out what changes need to be applied to make your wishes come true without maintaining/storing any additional information anywhere.
A simple DSF looks like the example below (which works with minikube):
[metadata] org = "example.com" # using a minikube cluster [settings] kubeContext = "minikube" [namespaces] [namespaces.staging] protected = false [namespaces.production] protected = true [helmRepos] stable = "https://kubernetes-charts.storage.googleapis.com" incubator = "http://storage.googleapis.com/kubernetes-charts-incubator" [apps] [apps.artifactory] name = "artifactory-prod" # should be unique across all apps description = "production artifactory" namespace = "production" enabled = true chart = "stable/artifactory" version = "6.2.0" # chart version valuesFile = "../my-artificatory-production-values.yaml" [apps.jenkins-test] name = "jenkins-test" # should be unique across all apps description = "test release of jenkins, testing xyz feature" namespace = "staging" enabled = true chart = "stable/jenkins" version = "0.9.1" # chart version valuesFile = "../my-jenkins-testing-values.yaml"
In addition to deploying Helm charts from code, Helmsman gives you the following features:
For more details on these features, refer to the documentation.
Helmsman has been helping us, and we are happy to share it with the community. It is open source and we welcome all forms of contributions and feedback. The project is hosted on Github.
Had enough of sluggish polling? With instant Artifactory event triggers you can give responsiveness in Jenkins a real boost. Here’s an easy way to set it up.
A super easy configuration guide
With the arrival of microservices code is becoming disposable. Does this mean that we no longer need maintainable code? Is it the end of refactoring?
Still relevant or increasingly redundant?
In software development tight coupling is one of our biggest enemies. On the function level it makes our application hard to change and fragile. Unfortunately, tight coupling is like the entropy of software development, so we have always have to be working to reduce it.
How to safely introduce modular architecture to legacy software.
I am an Atlassian certified trainer and over the years I have been spending much time with clients and their Jiras. In this blogpost, I have collected some small tips and tricks that will make your Jira usage better.
Jira Software is a powerful tool deployed in so many organizations, yet in day to day usage people are missing out on improvements, big and small.
In this post, I’ll take a closer look at the version of Jenkins X using Tekton, to give you an idea of how the general development, build, test, deploy flow looks like with Jenkins X. How does it feel to ship your code to production using a product coming from the Jenkins community that has very little Jenkins in it?
A crash course in Jenkins X and how to test it out on a local Kubernetes cluster
In this blog I will show you how to create snapshots of Persistent volumes in Kubernetes clusters and restore them again by only talking to the api server. This can be useful for either backups or when scaling stateful applications that need “startup data”.
Sneak peak at CSI Volume snapshotting Alpha feature
When I read Fowler’s new ‘Refactoring’ book I felt sure the example from the first chapter would make a good Code Kata. However, he didn’t include the code for the test cases. I can fix that!
Writing tests for ‘Theatrical Players’
Nicole Forsgren and the Accelerate DORA team has just released the newest iteration of the State of DevOps report. The report investigates what practices make us better at delivering valuable software to our users as measured by business outcomes. Read on for our analysis of the report, and how it can be best put to use.
The latest drivers of software delivery performance
A major challenge of software development is that our work is by and large invisible. This makes our folklore essential in business matters. Some of our commonly used arguments and visualizations are digital urban legends rather than solid foundations for informed decisions. Here, we’ll go through a few examples and some measures to address our misconceptions.
How the stories we tell influence our decisions
When you embark on your cloud native journey there will be important choices to make about cloud providers, continuous deployment, environments’ setup and separation. This guide will help you make the right choices by sharing lessons learnt from running cloud native apps in production.
Kubernetes has become the de facto container orchestration platform. When we help clients of different sizes and domains start their cloud native journeys in Kubernetes, we assist them in making sound decisions and technology choices. There is no one-size-fits-all solution when it comes to choosing cloud providers, CI tools, continuous deployment pipelines etc., so it is important to make the right decisions at the start. Failing to do so can be very costly in terms of lost time and money.
How to make the right technical choices on your cloud native journey
Hear about upcoming events in Scandinavia, latest tech blogs, and training in the field of Continuous Delivery and DevOps