Helm support about keel

[rusenask]

If I understand correctly - it would be another provider and events would trigger k8s updates through Helm?

If yes, then that's exactly why providers are pluggable :) Haven't used Helm for real deployments besides playing around with it but Helm looks like a great fit for the next provider.

[rimusz]

yes, you are correct - events would trigger k8s updates through Helm.

Can you add examples of pluggable providers, please? thanks

[rusenask]

providers have to implement two functions:

// Provider - generic provider interface
type Provider interface {
	Submit(event types.Event) error
	GetName() string
}

and then you can register new provider to the provider.Providers manager in main.go here https://github.com/rusenask/keel/blob/master/main.go#L102-L120
which will ensure that events are passed to all registered providers.

[rimusz]

I’m not the go guy, can you implement helm provider, please?

[rusenask]

say no more! I will put up a roadmap tonight since there seems to be a growing list of wanted features. Expect some questions on slack :)

[rimusz]

awesome

[rimusz]

any progress on helm integration?

[rusenask]

Okay, so a little update on progress. Maybe it's interesting for others as well. There are several pain points regarding helm integration:

1. gRPC API to tiller is there, but not documented and proto files seems to be not that stable but not a big problem.
2. Getting image names and tags from values.yml is trickier than I thought since those values can have any paths, ie:
   image.repository & image.tag, postgres.imageName, imageName and so on. Therefore this lookup should be somehow automated and dynamic, I have a plan for this but it will require some patience.
3. Currently the guidelines suggest to install Keel into keel namespace. Tiller by default runs in kube-system so we should either change it back to kube-system or add some docs on it.

It would be interesting to know how many people are interested in this feature, their use cases and their typical charts so the implementation could benefits them all.

[theckman]

@rusenask I'm going to copy and paste the message I send on Slack while we were chatting about this. Thanks again for pointing us to this project!

The one thing we've wanted is the idea of a "floating" image. In that we can update other settings of a Pod without needing to know what the current version is. It would prevent us from having to always keep the version in the helm chart, and assume something else was managing it. But to then make it easy to use the same chart to deploy new versions.

[rusenask]

Hi @theckman, could you elaborate more on this "floating" image? Usage example of this feature would be perfect.

Regarding keeping version in helm chart - with Keel you could omit version and it would automatically update to the latest semver version available. Of course, this would mean that k8s at first would get latest tag and keel would then switch it to something like 1.1.2. This is currently a good practice with k8s deployments, where in deployment you just specify your image without any tag.

[theckman]

Yeah. Sorry for being a bit vague. We work mostly in terms of Deployment resources, and we want to deploy Docker images that have tags based on SemVer. We also have helm charts that contain values.yaml files that vary based on the name of the environment. Our helm charts are laid out like this:

• values.yaml: default values for attributes
• <env_name>.yaml: a values file that overrides values for a particular environment
• <env_name>-secrets.yaml: a file that contains the secrets for the helm chart, protected with symmetric encryption keys managed by git-crypt. The secrets are kept with the normal configuration of our services.

When we deploy our helm charts, we often have an invocation that resembles this which compiles all of our values together:

$ helm upgrade <name> -f values.yaml -f dev.yaml -f dev-secrets.yaml .

One thing that would be great would be to avoid having to track the image in the values.yaml file. The reason we don't want to do this is that we had a bit of a outage after the version in the values.yaml file was deployed and it was no longer stable.

So say we are deploying a new service and we want to deploy v1.0.0. We choose that for the initial deployment be sent out. This is unavoidable because we don't want to track a version in values.yaml.

On our next deployment, say we want to change a log level from info to debug. In this case we'd want to update our configuration values, which triggers a restart of the pods, without having to remember which version to deploy.

It's quite possible how things are now will work for us, but I hope I was able to clear things up.

[rusenask]

Yeah it should work. Current Keel Helm provider creates a regular release with updated revision and it doesn't mess with Helm configuration in any way, just bumps version if newer is available for any release. On update it coalesces all values from previous revisions so your secrets & configuration should be safe.

So your workflow would be:

1. Install Keel either through k8s deployment or Helm chart ( @rimusz promised to make one 🥇 )
2. helm install -n <your service > -f values.yaml -f dev.yaml -f dev-secrets.yaml .
3. Upon newly updated images Keel will create new Helm release revisions: 1,2,3,4,..

And then just receive notifications on updated releaes (in this case only image tag was updated):

Revisions:

Bonus points:
Your each chart could have different update policies, ie:

• prod environment could have patch policy
• dev environment could have all policy to update everything all the time

[theckman]

That sounds awesome! Say I changed the deployment spec and want to distribute that too, we wouldn't be able to have keel push new helm changes? Just wanted to make sure I understand fully. 😄

[rusenask]

Yeah, it wouldn't do anything at the moment as it wouldn't know about it :) Currently the only triggers are dockerhub webhooks, GCR pubsub and registry polling for new images.

What you are describing regarding config change could be a 'git trigger' but then we would need a way to link github repositories with existing deployments. It could probably be done through annotations in k8s deployments and values.yaml in Helm. Not sure whether it actually fits in Keel's scope though :)

[rimusz]

implemented with v0.4.0