https://github.com/rimusz/cloud-builders-helm
GCP Cloud Build with Helm
https://github.com/rimusz/cloud-builders-helm
cloud-build continuous-deployment continuous-integration gke helm helm-tillerless kubernetes
Last synced: 7 days ago
JSON representation
GCP Cloud Build with Helm
- Host: GitHub
- URL: https://github.com/rimusz/cloud-builders-helm
- Owner: rimusz
- License: mit
- Created: 2017-07-14T16:16:09.000Z (almost 8 years ago)
- Default Branch: master
- Last Pushed: 2019-05-30T11:13:47.000Z (almost 6 years ago)
- Last Synced: 2025-04-17T02:28:49.113Z (9 days ago)
- Topics: cloud-build, continuous-deployment, continuous-integration, gke, helm, helm-tillerless, kubernetes
- Language: Shell
- Homepage:
- Size: 90.8 KB
- Stars: 28
- Watchers: 4
- Forks: 8
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# GCP Cloud Builder with Helm
This Cloud Builder runs [`helm`](https://github.com/kubernetes/helm) along with some [add-ons](#add-ons) and is available at `gcr.io/rimusz-lab1/cloud-builders-helm`
## Add-ons
It supports [Tillerless Helm](https://rimusz.net/tillerless-helm/) and comes with [helm-gcs](https://github.com/viglesiasce/helm-gcs), [helm-diff](https://github.com/databus23/helm-diff) and [helmfile](https://github.com/roboll/helmfile) baked in.
## Using this builder with Google Kubernetes Engine
To use this builder, your
[Cloud Build Service Account](https://cloud.google.com/cloud-build/docs/securing-builds/set-service-account-permissions)
will need IAM permissions sufficient for the operations you want to perform. For
typical read-only usage, the "Container Engine Viewer" role is sufficient. To
deploy container images on a GKE cluster, the "Container Engine Developer" role
is sufficient. Check the
[GKE IAM page](https://cloud.google.com/kubernetes-engine/docs/concepts/access-control)
for details.
For most use, `helm` will need to be configured to point to a specific GKE
cluster. That can be done using `kubectl` step (check [examples](examples))
where you need to configure the cluster by setting environment variables.
CLOUDSDK_COMPUTE_ZONE=
CLOUDSDK_CONTAINER_CLUSTER=
Setting the environment variables above will cause this step's entrypoint to
first run a command to fetch cluster credentials as follows.
gcloud container clusters get-credentials --zone "$CLOUDSDK_COMPUTE_ZONE" "$CLOUDSDK_CONTAINER_CLUSTER"`
The `kubeconfig` will be saved to `/workspace/.kube/config`, then, `helm` will
have the configuration needed to talk to your GKE cluster.
Example of `cloudbuild.yaml` file:
```
steps:
# fetch GKE cluster credentials to be used for helm step
- name: 'gcr.io/cloud-builders/kubectl'
env:
- 'CLOUDSDK_COMPUTE_ZONE='
- 'CLOUDSDK_CONTAINER_CLUSTER='
- 'KUBECONFIG=/workspace/.kube/config'
args: ['cluster-info']
# run helm command to install/upgrade filebeat
# optionally you can set to add any other Helm chart repository
# to use charts from
- name: 'gcr.io/$PROJECT_ID/cloud-builders-helm'
args: ['upgrade', '--install', 'filebeat', '--namespace', 'filebeat', 'stable/filebeat']
env:
- 'KUBECONFIG=/workspace/.kube/config'
- 'HELM_REPO_NAME=example'
- 'HELM_REPO_URL=http://charts.example.com'
- 'TILLERLESS=true'
- 'TILLER_NAMESPACE=test'
```
## Using Helm
This builder supports two install options of Helm:
* The default one when the `tiller` gets installed into your GKE cluster.
* Secure `Tillerless Helm` where `tiller` runs outside the GKE cluster.
### Default Helm + Tiller setup
The default one when the `tiller` gets installed into your GKE cluster (oh all those `tiller` security issues).
You can test e.g. installing a chart via `Helm`, running the following command.
gcloud builds submit . --config=examples/cloudbuild_not_tillerless.yaml
### Tillerless Helm setup
`Tillerless Helm` which solves all those `tiller` security issues, as `tiller` runs outside the GKE cluster.
I wrote a [blog post](https://rimusz.net/tillerless-helm/) how to use Helm local [tiller plugin](https://github.com/rimusz/helm-tiller).
You can test e.g. installing a chart via `Tillerless Helm`, running the following command.
gcloud builds submit . --config=examples/cloudbuild.yaml
**Note:** Also if your GKE cluster has `RBAC` enabled, you must grant Cloud Build Service Account `cluster-admin` role (or make it more specific for your use case), but for some reason Cloud Build uses Cloud Build Service Account `uniqueId` to authenticate to the GKE cluster instead of it's email address.
Below is example how to set it up with `uniqueId`.
# Get Cloud Build Service Account uniqueId
user=$(gcloud iam service-accounts describe [email protected] | grep -o 'uniqueId.*' | awk -v FS="('|')" '{print $2}')
# Grant Cloud Build Service Account `cluster-admin` role
kubectl create clusterrolebinding cluster-admin-your_project_id_sa --clusterrole cluster-admin --user [email protected]
kubectl create clusterrolebinding cluster-admin-$user --clusterrole cluster-admin --user $user
## Building this builder
To build this builder, run the following commands in this directory.
$ ./.scripts/set_tag.sh
$ gcloud builds submit . --config=.pipeline/cloudbuild.yaml
The first step sets Helm client version (stored in TAG file) to be used for building the image,
and the second builds the docker image and stores it under your GCP `project/helm` repo.
You can also automate builds by using `Container Registry build trigger` and connecting it your your `Github` repo
as per example below:
## Configuration
The following options are configurable via environment variables passed to the build step in the `env` parameter:
| Option | Description |
| ------------- | ------------- |
| HELM_REPO_NAME | External Helm repository name, optional |
| HELM_REPO_URL | External Helm repo URL, optional |
| TILLERLESS | If false, Tillerless Helm is disabled, optional |
| TILLER_NAMESPACE | Tiller namespace, optional |
| HELM_TILLER_HISTORY_MAX | maximum number of releases kept in release history, optional|