The Automation Broker works in conjunction with the Kubernetes Service Catalog to make services and applications easily deployable. An end user selects a service to be provisioned, selects a “plan” that describes the level of service (small, large, paid, free, persistent, ephemeral, etc), and then provides any required parameters. In this scenario, Helm charts can be utilized in two possible ways.
- The Automation Broker’s “helm registry adapter” can inspect a chart repository and make each discovered chart available as a service class. The chart’s
values.yaml
file is made available as a single parameter for a single default plan. - The tool
helm2bundle
creates a Service Bundle image that includes a specific chart. The image can be modified like any service bundle, including changes to metadata such as those inapb.yml
.
This post introduces the Helm registry adapter, making Helm charts available as service classes.
Deploy with the Helm Registry Adapter
Our Broker's application definition is written in Ansible as an Ansible Playbook Bundle (APB). This allows us to run the APB as a pod in the cluster, like below. Before deploying the Broker, just ensure that your cluster is running and has the service-catalog installed.
$ cat <<EOF | kubectl create -f -
---
apiVersion: v1
kind: Namespace
metadata:
name: automation-broker-apb---
apiVersion: v1
kind: ServiceAccount
metadata:
name: automation-broker-apb
namespace: automation-broker-apb---
# Since the Broker APB will create CRDs and other privileged
# k8s objects, we need elevated permissions
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: automation-broker-apb
roleRef:
name: cluster-admin
kind: ClusterRole
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
name: automation-broker-apb
namespace: automation-broker-apb
---
apiVersion: v1
kind: Pod
metadata:
name: automation-broker-apb
namespace: automation-broker-apb
spec:
serviceAccount: automation-broker-apb
containers:
- name: apb
image: docker.io/automationbroker/automation-broker-apb:latest
args:
- "provision"
- "-e create_broker_namespace=true"
- "-e broker_sandbox_role=admin"
- "-e broker_dockerhub_tag=canary"
- "-e broker_helm_enabled=true"
- "-e broker_helm_url=https://kubernetes-charts.storage.googleapis.com"
- "-e wait_for_broker=true"
imagePullPolicy: IfNotPresent
restartPolicy: Never
EOF
To follow the logs:
$ kubectl logs -n automation-broker-apb automation-broker-apb -f
Once the Broker is installed and registered with the service-catalog, you should see Helm charts listed as services in the OpenShift Web Console:
Using Helm Charts
There are two ways to make use of these Helm charts:
- Without Tiller - If Tiller cannot be found in the target namespace/project, then the objects are added to the cluster using the
helm template
command. - With Tiller - If Tiller can be found in the target namespace/project, then
helm install
is used to install the chart.
Provision "Tiller"
- From the list of available services in the OpenShift Web Console, select "Tiller".
- We will create a new project
helm-demo
where Tiller will be deployed and click Create.
Now, when we provision a Helm chart through the Web Console, it will use Tiller to carry out the installation.
Provision "Redis (Helm)"
Not all Helm charts work out of the box in OpenShift. This is most often related to the underlying container image being run as a non-root user (mongodb for example).
- Here, we will select "Redis (Helm)" from the list of available services in the OpenShift Web Console.
- We will configure "Redis (Helm)" by disabling the
securityContext
from thevalues.yaml
and click Create.
On success, in our helm-demo
project, we have a functional deployment of Tiller and Redis. We can even use the helm
cli tool:
$ helm version --short --tiller-namespace helm-demo
Client: v2.8.1+g6af75a8
Server: v2.8.1+g6af75a8
$ helm list -a --tiller-namespace helm-demo
NAME REVISION UPDATED STATUS CHART NAMESPACE
helm-141aff18 1 Tue Jun 19 10:36:01 2018 DEPLOYED redis-3.4.2 helm-demo
Summary
In this post we have shown that given a Helm chart repository, we can simply point the Automation Broker at it to expose Helm charts as services via the Kubernetes Service Catalog. Later, if you wish to modify or extend your Helm cart, you should have a look at Automating Helm Charts with Ansible.
About the author
Browse by channel
Automation
The latest on IT automation that spans tech, teams, and environments
Artificial intelligence
Explore the platforms and partners building a faster path for AI
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
Explore how we reduce risks across environments and technologies
Edge computing
Updates on the solutions that simplify infrastructure at the edge
Infrastructure
Stay up to date on the world’s leading enterprise Linux platform
Applications
The latest on our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Developer resources
- Customer support
- Red Hat value calculator
- Red Hat Ecosystem Catalog
- Find a partner
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit