Keel doesn’t need a database. Keel doesn’t need persistent disk. It gets all required information from your cluster. This makes it truly cloud-native and easy to deploy.
Keel can run anywhere and will do its job as long as it can connect to your Kubernetes environment. Since you have (or plan to have) Kubernetes environment, this guide will show you how to deploy Keel inside your Kubernetes cluster.
- Kubernetes environment (easiest way to get Kubernetes up and running is probably Google Container Engine or Docker for Mac with Kubernetes
- kubectl: Kubernetes client
We assume that your kubectl can access Kubernetes environment. If you have multiple environments, you should use kubectl config use-context [your cluster] command.
You can find sample deployments in https://github.com/keel-hq/keel repository under
deployments directory. You can either clone
whole repository or just download that file. Edit settings (depending on your environment whether you want to use Google Container Registry PUBSUB) or notifications and create it. All configuration is done through environment variables.
Some available configuration options:
- POLL - removing this environment variable will disable poll support.
- PUBSUB and PROJECT_ID - environment variables to enable automated integration with Google Container Registry. Set PROJECT_ID to your google cloud project ID.
- WEBHOOK_ENDPOINT - provide an endpoint where Keel should send notifications.
- SLACK_TOKEN - provide Slack token where Keel should send notifications, more info on getting token in the docs.
- HELM_PROVIDER - enable Helm provider.
Once you are happy with environment variables, create it:
kubectl create -f deployment-rbac.yaml
That’s it, to check whether it successfully started - check pods:
kubectl -n keel get pods
You should see something like this:
$ kubectl -n keel get pods
To remove Keel from your system, simply use existing deployment file:
kubectl delete -f deployment-rbac.yaml
Or delete the namespace.
Docker image polling and Kubernetes provider are set by default, then Kubernetes deployments can be upgraded when new Docker image is available:
helm repo up
If you want to install the Chart with Helm provider support:
Docker image polling is set by default, but we need to enable Helm provider support, then Helm releases can be upgraded when new Docker image is available:
helm upgrade --install keel stable/keel --set helmProvider.enabled="true"
Add the following to your app’s
values.yaml file and do
helm upgrade ...:
The same can be applied with
--set flag without using
helm upgrade --install whd webhookdemo --reuse-values \
You can read in more details about supported policies, triggers and etc in the docs.
Also you should check the Webhooh demo app and it’s chart to have more clear
idea how to set automatic updates.
To uninstall/delete the
helm delete keel
The command removes all the Kubernetes components associated with the chart and deletes the release.
The following table lists has the main configurable parameters (polling, triggers, notifications, service) of the Keel chart and they apply to both Kubernetes and Helm providers:
|polling.enabled||Docker registries polling||
|helmProvider.enabled||Enable/disable Helm provider||
|gcr.enabled||Enable/disable GCR Registry||
|gcr.projectID||GCP Project ID GCR belongs to|
|gcr.pubsub.enabled||Enable/disable GCP Pub/Sub trigger||
|webhook.enabled||Enable/disable Webhook Notification||
|webhook.endpoint||Remote webhook endpoint|
|slack.enabled||Enable/disable Slack Notification||
|service.enable||Enable/disable Keel service||
|service.type||Keel service type||
|service.externalPort||Keel service port||
|webhookRelay.enabled||Enable/disable WebhookRelay integration||
Specify each parameter using the
--set key=value[,key=value] argument to
Alternatively, a YAML file that specifies the values for the above parameters can be provided while installing the chart. For example,
helm install --name keel -f values.yaml stable/keel
Tip: You can use the default values.yaml.