Feature request: templated resources

[jcassee]

Maybe more of a scope question, but do you see keel as a solution for deploying multiple versions of the same container, for example to support (temporary) deployment of feature branches or pull requests?

[rusenask]

Since Keel doesn't create any deployments and just updates existing ones, this could be tricky.

On the other hand, it might be a good time to think about expanding it and maybe adding Git integration which might enable these features. What do you think would be responsible for building these images for feature branches and pull requests?

[jcassee]

Good question. In my setup the CI system builds the images and then calls a deployment job. That job basically checks both GitHub and Docker Hub to determine which resources to deploy (and destroy). It could be simplified if the CI system would delete tags of branches or PR when they are deleted and merged.

I'm not sure how to translate this to Keel's model. The definition would be a template and not a real Kubernetes Deployment itself. Also, to be useful you probably want to have a Service template too. The more I think about it the more it seems to be a completely different beast...

[azr]

It would be nice if somehow we could store those templates into a Docker image.

Like, by abusing the metadata or may be extending docker image builder. May be we could somewhat open a layer of the docker image and read files.

This would ask the question of how do you tell keel.sh what docker image you'd like to watch, like, by using a kubernetes keel.sh config file ?

[rusenask]

We could have a CRD in Keel that would allow to start watching images or git repositories. I think it could provide a nice interface.

[azr]

Oh, yes that's nice, so a git repo could be the controller of the changes.

I think a nice goal is to enable maintainment of more than 2 clusters easily. So we can get clusters closer to the users :)

[azr]

I'm trying to mentally push the idea of a self sustaining kubernetes docker image. To see if it goes somewhere interesting. That k8s pod specification could be in a label or as a file of a layer pointed at by a label ( such a file should be easy to crack up).

A docker k8s pod spec can optionally have :

• default name
• requested resources
• limits
• open ports
• metadata
• probes
• env var
• mounts

Then in a git repository, a deploy could define:

• images
• any of the above optionally

So a deployment could look like this :

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: potato
        image: nginx:v1  # keel updates patch & minor
      - image: xyz:v1.13 # keel updates minor
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    app: nginx
spec:
  ports:
  - port: 80
  selector:
    app: nginx

This in the end could generate a much bigger file. Then we would send a diff of them in slack for each docker push.

I would personnaly not recommend on having env variables in there, but more or less have everything be explicit.

[azr]

I this was going too far, this is not the right place and we don't need it, sorry :D. A followed repo is just enough.

[rusenask]

hmm, writing in a layer and then pointing to it does seem a bit complicated :D I have yet to have any time to think on how CRD interface would look like, need to prototype something first, then see what's missing.

I really like the simplicity that we have now, just a "self service" from developer perspective, labelling their own deployments. I wonder whether CRD introduction would affect it in a good or bad way.

[rusenask]

hey @azr, took gazillion years but wrote another thing for such cases :D https://about.sunstone.dev, it's written in Go and I will open source it too for self hosting, but basically it's like helm just without CLI/Tiller and you can set things like:

    spec:     
      containers:                    
        - image: keelhq/push-workflow-example:{{ .version | latestRegistrySemver "keelhq/push-workflow-example" }}

This template will forever have latest image and can be either used directly with kubectl or just curl to your machine to get the latest dep yamls:

curl https://sunstone.dev/raw.githubusercontent.com/keel-hq/keel/master/deployment/deployment-template.yaml\?namespace\=keel\&username
\=karolis\&password\=passpass\&relay_key\=$RELAY_KEY\&relay_secret\=$RELAY_SECRET\&relay_tunnel\=whr-keel\&tag\=alpha\&tiller_address\=tiller-deploy.kube-system.svc.cluster.local:44134 > keel.yaml

And then there are aliases that anyone can submit to the "hub" which is basically just a github repo that sunstone syncs to :) https://about.sunstone.dev/docs/#aliases