4 ms·

One thing that I think Kube (and dc/os) are missing is what Chef is working on right now. Application definition should live within the app and consumed by the

One thing that I think Kube (and dc/os) are missing is what Chef is working on right now. Application definition should live within the app and consumed by the scheduler. Chef's product is called Habitat https://www.habitat.sh/ https://www.habitat.sh/ and it has some VERY interesting concepts that if Kube will implement it will be much more interesting (to a lot of people). Right now, the deployment and configuration of an application is supposed to be separated but I feel they need to be just a bit more coupled. An engineer that develops the application will define a few things like "domain" and how you connect to the application and this will be consumed by the scheduler. Right now, dc/os and mesos are really fine grained around the DevOps people and I feel that the first that will crack the "batteries included" approach will win the fight by a knock-out. Imagine something like Heroku on your own infrastructure, if an engineer can launch and deploy a micro-service with the same ease they deploy and access a Heroku application. That will be awesome.

kozikow 10y ago
> Right now, the deployment and configuration of an application is supposed to be separated but I feel they need to be just a bit more coupled. You can dynamically configure kubernetes from within the cluster. You can either use client-go library or talk to the api server directly with rest. For other languages than Golang you may need to set up proxy server, but it's a single kubectl command. So all the basic functionality is there, but IMO configuration should be separate if it is possible - having it in source control is nice. I only use dynamic api for scheduling kubernetes jobs.
- avitzurel 10y ago
  What I imagine is something like the Procfile for Heroku. The app decides what it runs and how, you can set configuration like domain, whether the application is public/private etc... Once you push the application to the scheduler it will handle the rest.
  - kozikow 10y ago
    Ah. Quite a lot of things you mention are possible by dynamically generating yaml config. I wrote a blog post about using go kubernetes library to generate yaml : https://kozikow.com/2016/09/02/using-go-to-autogenerate-kubernetes-configs/ https://kozikow.com/2016/09/02/using-go-to-autogenerate-kube.... It's quite nice, even for static config IMO, due to type safety. You can easily write golang binary that would ask user series of questions "what database would you like", "do you want public access", etc. and get yaml as output.
    - avitzurel 10y ago
      Yup. What I am saying is this: This should be a part of the core offering IMHO. I think most people choose Heroku over rolling their own infrastructure simply because of the ease-of-use for getting started.
  - ecnahc515 10y ago
    That's basically what Deis does. They use Kubernetes as the backbone and build a heroku layer on top.
hosh 10y ago
From a different perspective, it's great to see Chef making a credible play in the container space.
cies 10y ago
Have you seen Deis? It seems they put just that, private-Heroku, on top of K8s. It even supports Heroku's buildpacks. https://deis.com/ https://deis.com/
- avitzurel 10y ago
  I've looked at their docs many many times. Never took the plunge.
lobster_johnson 10y ago
While coupling is convenient, there is a problem when you are not the only consumer of your code. If you have an open source project that is to be deployable by anyone, you can't put Kubernetes files there (there's not really a way to write a generic Kubernetes manifest -- in addition to volumes and secrets, things like labels are environment-specific). This is also true for other things like .drone.yml for Drone. So you have to maintain a private "release fork" that you periodically rebase into. This becomes a workflow bottleneck, and the VCS history will not look good, either. Even worse if you have multiple branches you deploy from.
- avitzurel 10y ago
  This is true. It's especially true if you have services depending on one another. I think there's a middle-ground there. Right now, 99% of people I know use Github-Workflow, master is always deployable (often CD), other branches are able to deploy using "hubot deploy branch-name to xxx" I think if you take the latter and you make it easier to deploy an application on top of your cluster, you can gain a lot. The workflow today is more cumbersome. If you could create your application, attach some definitions to it and launch it to the scheduler, it would be better.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]

kozikow 10y ago

> Right now, the deployment and configuration of an application is supposed to be separated but I feel they need to be just a bit more coupled. You can dynamically configure kubernetes from within the cluster. You can either use client-go library or talk to the api server directly with rest. For other languages than Golang you may need to set up proxy server, but it's a single kubectl command. So all the basic functionality is there, but IMO configuration should be separate if it is possible - having it in source control is nice. I only use dynamic api for scheduling kubernetes jobs.

avitzurel 10y ago
What I imagine is something like the Procfile for Heroku. The app decides what it runs and how, you can set configuration like domain, whether the application is public/private etc... Once you push the application to the scheduler it will handle the rest.
- kozikow 10y ago
  Ah. Quite a lot of things you mention are possible by dynamically generating yaml config. I wrote a blog post about using go kubernetes library to generate yaml : https://kozikow.com/2016/09/02/using-go-to-autogenerate-kubernetes-configs/ https://kozikow.com/2016/09/02/using-go-to-autogenerate-kube.... It's quite nice, even for static config IMO, due to type safety. You can easily write golang binary that would ask user series of questions "what database would you like", "do you want public access", etc. and get yaml as output.
  - avitzurel 10y ago
    Yup. What I am saying is this: This should be a part of the core offering IMHO. I think most people choose Heroku over rolling their own infrastructure simply because of the ease-of-use for getting started.
- ecnahc515 10y ago
  That's basically what Deis does. They use Kubernetes as the backbone and build a heroku layer on top.

hosh 10y ago

From a different perspective, it's great to see Chef making a credible play in the container space.

cies 10y ago

Have you seen Deis? It seems they put just that, private-Heroku, on top of K8s. It even supports Heroku's buildpacks. https://deis.com/ https://deis.com/

avitzurel 10y ago
I've looked at their docs many many times. Never took the plunge.

lobster_johnson 10y ago

While coupling is convenient, there is a problem when you are not the only consumer of your code. If you have an open source project that is to be deployable by anyone, you can't put Kubernetes files there (there's not really a way to write a generic Kubernetes manifest -- in addition to volumes and secrets, things like labels are environment-specific). This is also true for other things like .drone.yml for Drone. So you have to maintain a private "release fork" that you periodically rebase into. This becomes a workflow bottleneck, and the VCS history will not look good, either. Even worse if you have multiple branches you deploy from.

avitzurel 10y ago
This is true. It's especially true if you have services depending on one another. I think there's a middle-ground there. Right now, 99% of people I know use Github-Workflow, master is always deployable (often CD), other branches are able to deploy using "hubot deploy branch-name to xxx" I think if you take the latter and you make it easier to deploy an application on top of your cluster, you can gain a lot. The workflow today is more cumbersome. If you could create your application, attach some definitions to it and launch it to the scheduler, it would be better.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]