4 ms·

This is basically what we're doing: With each app, we put the chart in the app's repo itself, and we built a wrapper around Helm that performs deploys for us, u

This is basically what we're doing: With each app, we put the chart in the app's repo itself, and we built a wrapper around Helm that performs deploys for us, using "helm upgrade --install ./k8s" from the file system. Keeping the chart with the app means it's versioned along with the app. (It's not a general-purpose wrapper; it's the CLI we use to manage anything related to our clusters and apps, basically: DNS, secrets, ad-hoc shells etc.) One of the things this wrapper does is ensure that every deploy is annotated with metadata — git revision, git branch, git repo, and also who deployed it. This allows a developer to run a status command to determine what versions of each app are currently deployed, and also show a log of new commits that haven't been deployed yet. It also means you can easily see that an app was deployed from a specific branch, for example. I think Helm's design is a bit flawed here. It's catering to two different purposes: One is deploying packaged versions of third-party software (e.g. PostgreSQL); the other is deploying your own software. There's an inherent conflict there in that the release process is different. Why can't Helm pull directly from git and use its revisions as version numbers? It doesn't make any sense for us to "publish" an app to a "repository" when we already have git. Right now, we're basically using Helm as a glorified templating system, and it's a somewhat buggy one, so we may decide to ditch Helm and use a pure templating solution instead. I haven't looked at Draft, but seeing as it's based on Helm, I'm not sure that it can improve on the basic design?

yebyen 9y ago
Draft is a very simple tool and it's not just based on Helm, it is using Helm under the hood. You will probably not find much use for Draft given the more advanced state of your tooling. It's been described as "a gateway drug to k8s" because, for the uninitiated, it simplifies the process of "OK, I want to put my app on K8s, what now?" – it sets you up with a reasonable default chart, and a dummy Dockerfile based on what kind of app the Draft logic decides your app is. (Eg. it's going to recommend ruby:onbuild if you have a Ruby app.) That might work out of the box, more likely you need to make some changes in the Dockerfile, but that could very well be all. It's really more like an advertisement for Deis. It's the "zeroconf" version of Deis. If you've never heard of Deis, I'll be happy to tell you more about that; Deis has a builder service/pod and acts as a git repository, so you set it up as a git remote with the deis commandline tool and 'git push deis' to prompt a release upgrade. It is more likely what you are probably expecting as a piece of your CI/CD solution. For people that aren't already fluent users of git, k8s, helm, charts... Draft is easier to get started with, and it gives a chance to expose you to all of those things, without making any of it prerequisite knowledge to spin up your app on k8s at once. For literally anyone else, you're going to get a much better experience from Deis, which is not only out of Beta but long past the 2.0 milestone (when it moved to K8s from the prior CoreOS/Fleet-based stack.) Deis is installed via helm, but after that you do not need to use the Helm client. Your apps can use Procfile-style or Dockerfile for deployments. The builder is very modern and developed, and as it evolves, it picks up a lot of efficiencies that you might have seen before on Heroku if you're familiar with that platform, making it very convenient to work with. (That also means it brings the baggage of 12-Factor, if you consider that as baggage...)
- yebyen 9y ago
  To be clear, I think that Deis is using helm under the hood too, but you never have to interact with helm or your chart. Draft is written so you could probably avoid ever running the helm client, but it is a much thinner layer of sugar on top. You are very near the helm charts, but in Deis you might never even realize that there are helm releases associated with your app. The Deis client interface is pretty fully featured, almost drop-in as a comparison to heroku client. Using Draft, you are encouraged to edit your charts, but with Deis it is well-hidden and there is probably never any need to do that. Service brokers (for supporting dynamic allocation of things like shared instances of postgres and redis, like you get with heroku) are a thing, but they are newer and I have not seen them being used in practice yet.
- lobster_johnson 9y ago
  By Deis, are you referring to Workflow? [1] There's no product called "Deis" anymore. Workflow seems too high-level and large for my taste. It's an entire PaaS on top of Kubernetes, which also brings way too much to the table (edge routing, log/metrics management, alerting, etc.). [1] https://deis.com/workflow/ https://deis.com/workflow/
ianburrell 9y ago
The advantage of Helm over static K8s configs or simple templates is that charts can use other charts for complex dependencies, and can have multiple releases with different values. The latter is useful for different environments (dev, staging, production) or for changing dynamic values separate from template code (replicas, resources, versions).
- lobster_johnson 9y ago
  As long as Helm can't pull dependencies directly from git, it's still not a good fit for git-versioned repositories.
  - yebyen 9y ago
    Try Deis. It's a little more constraining, but it uses Helm under the hood, and it uses a git commit as the basis of each release.

yebyen 9y ago

Draft is a very simple tool and it's not just based on Helm, it is using Helm under the hood. You will probably not find much use for Draft given the more advanced state of your tooling. It's been described as "a gateway drug to k8s" because, for the uninitiated, it simplifies the process of "OK, I want to put my app on K8s, what now?" – it sets you up with a reasonable default chart, and a dummy Dockerfile based on what kind of app the Draft logic decides your app is. (Eg. it's going to recommend ruby:onbuild if you have a Ruby app.) That might work out of the box, more likely you need to make some changes in the Dockerfile, but that could very well be all. It's really more like an advertisement for Deis. It's the "zeroconf" version of Deis. If you've never heard of Deis, I'll be happy to tell you more about that; Deis has a builder service/pod and acts as a git repository, so you set it up as a git remote with the deis commandline tool and 'git push deis' to prompt a release upgrade. It is more likely what you are probably expecting as a piece of your CI/CD solution. For people that aren't already fluent users of git, k8s, helm, charts... Draft is easier to get started with, and it gives a chance to expose you to all of those things, without making any of it prerequisite knowledge to spin up your app on k8s at once. For literally anyone else, you're going to get a much better experience from Deis, which is not only out of Beta but long past the 2.0 milestone (when it moved to K8s from the prior CoreOS/Fleet-based stack.) Deis is installed via helm, but after that you do not need to use the Helm client. Your apps can use Procfile-style or Dockerfile for deployments. The builder is very modern and developed, and as it evolves, it picks up a lot of efficiencies that you might have seen before on Heroku if you're familiar with that platform, making it very convenient to work with. (That also means it brings the baggage of 12-Factor, if you consider that as baggage...)

yebyen 9y ago
To be clear, I think that Deis is using helm under the hood too, but you never have to interact with helm or your chart. Draft is written so you could probably avoid ever running the helm client, but it is a much thinner layer of sugar on top. You are very near the helm charts, but in Deis you might never even realize that there are helm releases associated with your app. The Deis client interface is pretty fully featured, almost drop-in as a comparison to heroku client. Using Draft, you are encouraged to edit your charts, but with Deis it is well-hidden and there is probably never any need to do that. Service brokers (for supporting dynamic allocation of things like shared instances of postgres and redis, like you get with heroku) are a thing, but they are newer and I have not seen them being used in practice yet.
lobster_johnson 9y ago
By Deis, are you referring to Workflow? [1] There's no product called "Deis" anymore. Workflow seems too high-level and large for my taste. It's an entire PaaS on top of Kubernetes, which also brings way too much to the table (edge routing, log/metrics management, alerting, etc.). [1] https://deis.com/workflow/ https://deis.com/workflow/

ianburrell 9y ago

The advantage of Helm over static K8s configs or simple templates is that charts can use other charts for complex dependencies, and can have multiple releases with different values. The latter is useful for different environments (dev, staging, production) or for changing dynamic values separate from template code (replicas, resources, versions).

lobster_johnson 9y ago
As long as Helm can't pull dependencies directly from git, it's still not a good fit for git-versioned repositories.
- yebyen 9y ago
  Try Deis. It's a little more constraining, but it uses Helm under the hood, and it uses a git commit as the basis of each release.