keel

I am a solo developer and I have been running my side projects on Kubernetes (GKE) for several years now. It helped me a lot to focus on things that I like: development instead of ops. I never had to SSH into any machine or do things manually. I just tag a github release and in few minutes I get my application updated. With Docker I believe it would be lot more complicated, no zero-downtime upgrades, no load balancing, OS vulnerabilities. Then, when I would need to add a new service into my setup, I would have to yet again go into the host or multiple hosts :) So no, I don't believe people who say that for small projects you shouldn't use K8s. It saves a lot of time and helps you not to burn out on your side projects as it takes the pain of running a service away. P.S. I am an author of Keel https://github.com/keel-hq/keel, it's a relativ

I have been using this for several years now. Great stuff! :) The only part that was missing from this was something that can update your deployments on image build. That's when I built Keel https://github.com/keel-hq/keel. Basically, I have one trigger to always build from master but the rest are triggered by tag, for example, "1.2.5" and it builds the same image, then Keel updates affected workloads. So far I have never had to pay for it, apparently managing to stay in the free tier :) Works way faster than automated Docker cloud builds either.

Hi, if you would want Keel to support Docker Swarm, please create an issue here: https://github.com/keel-hq/keel/issues. I planned to add Docker Swarm support from the beginning but a lot of people said that it's unnecessary. It's quite simple to add new providers, they need to implement this interface: // Provider - generic provider interface type Provider interface { Submit(event types.Event) error // <- this is where new image event comes in TrackedImages() ([]*types.TrackedImage, error) // <- provider needs to tell some triggers which images to track (registry watcher) GetName() string Stop() } Even though Keel was created for Kubernetes, later on Helm was added where Keel talks directly to Tiller and doesn't really use K8s API.

I have two projects that talk directly with k8s, it's keel (CI tool for kube) https://github.com/keel-hq/keel and ingress controller for webhookrelay.com so I need a working cluster locally. However, other services are also tested on local minikube as it's easier to make sure they are interacting as intended when running in K8s :)