We’ve been using a similar solution for a while now: pushes to GitHub trigger Travis CI to build a Docker images. These get pushed to Docker Hub or Quay, which triggers a webhook to Keel.sh running in our Kubernetes cluster. Keel then updates the Kubernetes deployment to perform a rolling update of the application.
Red Hat's OpenShift Kubernetes distribution can do this too - you even get a webhook for GitHub copy and paste.
Kubernetes is a toolbox, not a product. There's so much you have to set up yourself (build system, registry, security, logging stack, metrics...). That's fine if you're in the business of selling Kubernetes itself, but otherwise, most teams should use something like OpenShift and not re-invent the wheel.
Google released a tool to help with continuous deployments called skaffold . Haven't used it myself (just using bitbucket pipelines) but looks like it's a relevant tool to this. Nice.
I really like when deployment tools rely on git hooks and doesn't require any other installations in dev environment.
Close to opening up a service that does this for pull request branches, from GitHub to AWS ECS/Fargate.
Glad to see this kind of workflow gaining momentum.
I wonder how this tool handles performing the docker build itself. It looks like it runs a controller inside the cluster, but by default apps running inside kubernetes don't get access to the docker daemon.
There are a few existing workarounds, but none of them are terribly appealing.
See this longstanding issue for some more context: https://github.com/kubernetes/kubernetes/issues/1806
I deploy via git-push to Travis CI which then runs my test suites and if they pass, continues on with the deployment to the (virtual) hardware server via https://www.gigalixir.com/ (it's an Elixir Phoenix web app).
A properly set up CI is awesome and a huge timesaver.
I use https://github.com/dminkovsky/kube-cloud-build for this, which uses Google Cloud Container Builder to perform builds. It’s a really nice workflow!
Looks a lot like http://github.com/weaveworks/flux which we're happy users of at dotmesh.com.
Glad to see gitops getting some traction! https://www.weave.works/blog/gitops-operations-by-pull-reque...
This certainly does seem to be a fairly easy way to deploy. I'm assuming you'd integrate standard ci/cd tools in via webhooks? Or even pre-push scripts?
I’ve been using drone.io to do this for a month now. Loving it:
- git push starts the process - build and deploy images to google cloud with the plugins/gcr tool - set the image in kubernetes in the next step using the google cloud sdk image
I run unit tests as a docker build step. If they fail, it won’t deploy. If the readiness probe fails after setting it in kubernetes, it won’t switch over!
I was thinking of hasura.io while reading the page only to find this is a hasura project - Keep up the great work
Interesting, and real nice! I built something similar for my raspberry pi cluster with docker swarm (albeit no testing and tailored to my use case).
Kicking myself for not making "production ready" and posting here now.
Keel does a really good job of this, good to see people are starting to have options with their k8 deployments!
My two cents:
So far my deployments have been pretty painless, so changing over to something like Gitkube / keel isn't my top priority currently.
Configuration management / Creating my kubernetes resources ( deployments / services / ingress / etc. ) in a repeatable and elegant way is my biggest pain point by far.
I've been very unhappy with Helm.
Helm is insanely verbose. Go ahead and take a look at the kubernetes/charts repo and look at the various stable charts. Note the huge amount of copy-pasta code hanging out.
Too much of my life has been spent wrangling YAML templates that are rendered using the under-featured gotmpl library.
Also, helm's client library support is less than stellar. Also, schlepping my configurations around is a pain.
In Helm, it's a crazy amount of code to implement a `ingress -> service -> deployment` pattern that is standard for 99% of kubernetes resources. You have to write the same things over and over, which means that making changes takes forever and is brittle.
I believe this is due to gotmpl being a poor templating engine for this use case. It doesn't have enough features to allow one to develop decent abstractions over declaring k8 resources
The helm tiller doesn't expose a restful API or proper tooling to allow other resources to interact with it effectively, making automated deployments a chore. My only option is to call out to the shell and try and be devensive.
Finally, Helm doesn't really do that great a job of validating my resources are going to be valid. `helm install --dry-run` will tell you everything is great, and then break in the middle of an actual installation, leaving a half-configured mess in it's wake.
KSonnet looks like an attractive option, it's certainly less verbose. But the documentation isn't there yet, and if you peek under the hood there is a MOUNTAIN of ksonnet code waiting to be read and understood. I belive it's going through some churn currently, so features and impovements have been slow to appear.
Also KSonnet doesn't have enough example implementations to hit the ground running when trying it out on my clusters.
Targeting individual contexts in Ksonnet provides some nice additional safety, and some very simple implementations using google KMS or something similar could be a really special way to safely store my secret configs at rest, similar to ansible-vault.
Terraform has this NAILED in the VM space. I declare my environment: `terraform plan` tells me what is going to happen, `terraform apply` checks to ensure I've not protected any of my resources with a flag, and applies the changes it listed if not.
I'd love to write my k8 resources in terraform, but it doesn't currently support modern k8 resources, and I don't LOVE how terraform handles storing my tfstate files either way.
Wow! This is highly relevant to my troubles this morning, and solves a highly relevant pain-point. I would not be surprised to find something like this mainlined into k8s over time... Nicely done :)
Why not just `git push`, `docker build`, `kubectl set image`?
This looks exactly what I had been looking for these days. None of existing solutions fit my use case. Thanks for making this, I will give it a try soon.
Good work from Team Hasura! Also liked the HDFS on k8s tutorial posted sometime back.
This is awesome! Thanks for open-sourcing :)
This is a beauty! Excellent work.