-
-
Notifications
You must be signed in to change notification settings - Fork 579
Support for Kubernetes #1118
Comments
Also relevant to the party here: https://github.com/tentsk8s/buffanetes |
I'll x-post some stuff I wrote in slack about buffanetes a few mins ago. I also cleaned up some of my foul language 😄
Oh and one thing to add - I didn't write this as a plugin, I wrote it as a separate binary because I was trying to make myself feel special (I don't need no stinkin plugins!) That was not the right decision - I think it should absolutely be a plugin 😄 |
There are a couple of Buffalo plugins that deploy to Kubernetes, is the goal here to have something builtin to the buffalo binary, instead of a plugin? |
@bscott I'd love to check them out, can you link it? I don't think the goal is to build directly into the binary - just a plugin. Wasn't aware that there were already plugins for that. |
I started mine right before I found yours @arschles ;) |
That's awesome @bscott! Feel free to copy whatever code you want from buffanetes if it's useful, I have like no time right now to do anything with the project soon I hope! |
Also, I love the Kube + Buffalo party that's going on here! |
@bscott any links to show how to use the k8 plugin ? |
Right now Go buffalo creates a
Dockerfile
in a user's application. I think we could take that a step further and add support for deploying a Buffalo application to Kubernetes.I presented a keynote at VelocityConf this year, and did a live demo of deploying a buffalo app to Kubernetes. The application can be found here and the manifests I used to deploy in Kubernetes can be found here.
The way Kubernetes works is that you need to define various resources to create in your cluster (usually in YAML). When those resources are all deployed correctly you should have a working (publicly available) application. A list of the resources I created when I ran my Buffalo application in Kubernetes:
Example Kubernetes Resources
Buffalo Application
Postgres Database
Ingress controller
Dynamic Configuration Problem
As we know Buffalo lets users pick various options while building there application. In some cases, these options will need to trickle down into the Kubernetes resources that would be defined. An example would be changing a database from Postgres to something else.
Ksonnet
There are tools like ksonnet that abstract the Kubernetes resources needed to define an application. We could leverage ksonnet's ability to have multiple flavors of an application to handle the dynamic configuration problem
Helm
Most Kubernetes users are familiar with Helm. We could write a
Chart
that helm could then read and deploy. Helm would also allow us to define various dynamic configuration and logic to include/exclude various resources. The main difference between Helm and Ksonnet is Ksonnet uses an abstraction, where Helm is just a templating language (text/template).Success
As a user I can create an arbitrary Buffalo application, and in less than 3 commands I can easily have my application running in a properly configured Kubernetes cluster.
As a user who deployed their application to Kubernetes I can easily find a resolvable address where my Buffalo application can be found at.
The text was updated successfully, but these errors were encountered: