Checking in your deployment configuration as code
Helm is a tool that streamlines the creation, deployment and management of your Kubernetes-native applications. In this talk, we take a look at how Helm enables you to manage your deployment configurations as code, and demonstrate how it can be used to power your continuous delivery (CI/CD) pipeline.
20. Helm + Jenkins vs. Spinnaker
Helm and Jenkins
+ config as code, single source of truth
+ multi-branch support (including pull requests)
+ rich source of plugins
+ single platform for CI and CD
Spinnaker
- more deployment strategies
21. Helm Community
Over 100 contributors
1.5 years old
Slack channel: Kubernetes/#Helm
Public dev meetings: Thursdays @ 9:30 pacific
Weekly updates & demos at SIG-Apps meetings: Mondays @ 9am pacific
Join
us!
Tools that define configuration or infrastructure as code have existed for a long time, such as Chef and Puppet
More recently we've seen this extend to CI pipelines, packaging with Dockerfiles, Packer config, and Infrastructure on clouds with Terraform and AWS CloudFormation, and more recently with Kubernetes and Helm
Single source of truth for all configuration
Gives you consistency across your deployments and tools
Declarative definitions allow for reproducibility
Version control comes with goodies
In this talk, we'll take a look at how to build a whole CI/CD pipeline out of these tools
In Kubernetes, you would define and create multiple resources for each of these tiers
Deployment resource - describes what containers to run in the service, how to scale them, healthchecks, resources
Service resource - enables service discovery and loadbalancing for your deployments
Secret/ConfigMap resource - your application may take in a password or API token that needs to be kept secret
Each resource is a declarative definition usually written in YAML or JSON
When you want to go and upgrade your templates to release a new version of your application, you need to manually edit these files to change the tag of the docker image
or if you want to change configuration in the configmap
this is painful and hard to automate
after making changes, it's difficult to rollback to a previous state because history is not tracked for every resource
if your application needs to run a database migration during an upgrade
you need to build tooling to manage this during your release process
Helm allows you to reduce boilerplate and reuse resources in intelligent ways
e.g. provides a public repository to take common components from
Bundling different resources together and reordering into dependencies makes resources easier to manage and update
Helm allows you to hook into your deployments and run database migrations at certain points in the deployment process
Packages in Helm are called Charts
They consist of metadata, templates, config files and docs
They can depend on other charts
Mostly the same as before, but Helm packages this all as a bundle
Also containers metadata, docs, config file for exposing configuration for your app during install-time
Laid out into two chart repos:
Incubator - great place for sharing and developing ideas, and trying out new k8s alpha features
Stable - a place for curated, ready-to-run applications
Build - Docker
Test - ???
Release artifacts - Image registry
Manual verification - Yes no, maybe so? Staging environment
Deploy - Production
Build - Docker
Test - ???
Release artifacts - Image registry
Manual verification - Yes no, maybe so? Staging environment
Deploy - Production
