Paweł Prażak
Feb 28, 2018 · 5 min read

Deis (now part of Microsoft) created an interesting three part ecosystem:

The power trio

Helm is a package manager and template engine for Kubernetes applications

Draft is the “inner loop” of a developer’s workflow: code, deploy, commit

Brigade is an event-based pipeline scripting tool for Kubernetes

I’m familiar with Helm and see a potential in Draft, but what I’m really interested in is the Brigade CI capabilities.

I’ll cover installation of all three projects and have a closer look at the last one.

Installation

Install Helm binary:

curl -#L \
--url https://kubernetes-helm.storage.googleapis.com/helm-v2.8.1-linux-amd64.tar.gz \
| tar zx -C ~/bin linux-amd64/helm
mv ~/bin/linux-amd64/helm ~/bin/helm
rmdir ~/bin/linux-amd64/

Install Draft binary:

curl -L# \
--url "https://azuredraft.blob.core.windows.net/draft/draft-v0.10.1-linux-amd64.tar.gz" \
| tar xzv -C ~/bin linux-amd64/draft
mv ~/bin/linux-amd64/draft ~/bin/draft
rmdir ~/bin/linux-amd64/

Simple Helm and Draft deployment:

kubectl config use-context mycluster
kubectl create namespace draft
kubectl --namespace draft \
create serviceaccount tiller
cat << EOF | kubectl create -f -
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: tiller-binding
namespace: draft
subjects:
- kind: ServiceAccount
name: tiller
namespace: draft
roleRef:
kind: ClusterRole
name: admin
apiGroup: rbac.authorization.k8s.io
EOF
kubectl --namespace draft \
run registry --image registry --port 5000
kubectl --namespace draft \
expose deployment registry --port 80 --target-port 5000
helm --tiller-namespace draft init \
--service-account=tiller
draft --draft-namespace draft init
# 1. (...) registry URL: registry.draft.svc.cluster.local
kubectl --context mycluster --namespace draft get all,secret,sa,cm

I deviated from the docs, because I really want to use Kubernetes built-in cluster role admin.

Simple Brigade deployment:

helm repo add brigade https://azure.github.io/brigade
helm --tiller-namespace draft install brigade/brigade \
--name brigade --namespace draft \
--set rbac.enabled=true \
--set gw.enabled=false \
--set cr.enabled=false

I don’t want to create any ELBs and don’t really need any of the gateways.

Unfortunately as at the time of writing this won’t work as expected: #327, PR328. Here’s my fork with some fixes applied if you are interested.

(Edit: since this post was written a new version was released: v0.10.0)

If we want a fancy UI, there’s Kashti — and experimental dashboard for Brigade.

A little more work for Kashti:

git clone https://github.com/Azure/kashti.git
cd kashti
helm --tiller-namespace draft install charts/kashti \
--name kashti \
--namespace draft \
--set service.type=ClusterIP \
--set brigade.apiServer=http://localhost:7745

We’ll need to make the Brigade API available locally:

kubectl --namespace draft port-forward $(kubectl get pods --namespace draft -l "app=brigade-brigade-api" -o jsonpath="{.items[0].metadata.name}") 7745

Finally let’s port forward to Kashti UI:

kubectl --namespace draft port-forward $(kubectl get pods --namespace draft -l "app=kashti,release=kashti" -o jsonpath="{.items[0].metadata.name}") 8080:80
Empty UI

Now we need to add brig CLI tool:

go get github.com/Azure/brigade
cd $GOPATH/src/github.com/Azure/brigade
dep ensure -v
make brig

There’s no install target so you need to make it available on $PATH. There’s the issue #330 about this.

Usage

With all that in place we can take it for a spin. First let’s look at the example.

First we need to create a project for brigade:

cd $GOPATH/src/github.com/Azure/brigade
helm inspect values brigade/brigade-project > myvalues.yaml
helm --tiller-namespace draft install brigade/brigade-project \
--namespace draft \
--name deis-empty-testbed \
-f myvalues.yaml
brig --namespace draft run -f brigade.js deis/empty-testbed

This should result in a build and project being listed in brig:

brig --namespace draft build list
ID TYPE PROVIDER PROJECT
01c79a27q054bsgaax211z6r7j exec brigade-cli brigade-830c16d4aaf6f5490937ad719afd8490a5bcbef064d397411043ac
brig --namespace draft project list
NAME ID REPO
deis/empty-testbed brigade-830c16d4aaf6f5490937ad719afd8490a5bcbef064d397411043ac github.com/deis/empty-testbed

Also UI should reflect the new project.

Homepage with the new project
Project screen

Unfortunately the job is red. Here’s a cryptic error message from brig:

yarn run v1.3.2
$ node prestart.js
prestart: src/brigade.js written
$ yarn build && node --no-deprecation ./dist/index.js
$ tsc
[brigade] brigade-worker version: 0.9.0
[brigade:app] Error: Project not found: Error: unable to get issuer certificate

- k8s.js:96 defaultClient.readNamespacedSecret.catch.reason
./dist/k8s.js:96:31

Build finished with unhandledRejection state
[brigade:app] error handler is cleaning up
error Command failed with exit code 1.

Since I’ve timeboxed this to one day, and it’s already two, I’m afraid I’ll have to stop here.

Cleanup

To cleanup your cluster just do the reverse mostly.

First let’s have a look at what we have installed (edited for clarity):

helm --tiller-namespace draft list
NAME REV UPDATED STATUS CHART NAMESPACE
brigade 2 Mon ... DEPLOYED brigade-0.9.0 draft
deis-empty-testbed 1 Mon ... DEPLOYED brigade-project-0.9.0 draft
draft 1 Sun ... DEPLOYED draftd-v0.10.1 draft
kashti 1 Mon ... DEPLOYED kashti-0.1.0 draft

Delete Helm charts:

helm --tiller-namespace draft del --purge deis-empty-testbed kashti brigade draft

Delete Kubernetes namespace:

kubectl delete ns draft

You might also want to cleanup all the directories and files we’ve created.

Summary

This is as far as I’ve got in about two days. There was some debugging and code reading involved to get to this stage. I’m sure given enough time the experience will be smooth. Part of the problem was my insistence on not deploying it in default namespace and using proper RBAC.

From what I’ve seen Helm is mostly feature complete and quite mature, and the other projects are still in the early stages.

If any of you had better luck with this I would be happy to have your insight — feel free to comment.

I really like the concepts and ambition behind these projects, so kudos to all of you involved in making all of this possible.

VirtusLab

Virtus Lab company blog

Thanks to Pawel Dolega

Paweł Prażak

Written by

Software Engineer, DevOpsSec

VirtusLab

VirtusLab

Virtus Lab company blog

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade