No. Sugarkube just runs commands. It’s up to you what they do.
Helm installs individual applications (e.g. Wordpress) but gets complicated if you want to install a suite of related applications (e.g. a monitoring stack with Prometheus, Grafana, Elastic Search and various beats like filebeat, metricbeat, etc.). You could create a ‘superchart’ that defines all these as dependencies, but then you have little control over just installing a subset of your charts.
Sugarkube gives you a simple way to specify, for example, that
ChartA at version
a.b.c should be installed alongside
ChartB at version
Helm charts also don’t create any required infrastructure. An application like Chart Museum should probably be backed by S3 in production (if you’re on AWS), but Helm leaves it up to you to work out how to create that S3 bucket. This gets more complicated if you have further dependencies like needing to first create KMS keys for S3 bucket encryption.
Because Sugarkube was written with provisioning from bare metal in mind you can configure it to install kapps that create shared infrastructure resources like load balancers, CloudFront distributions and KMS keys. These can then be used by e.g. Chart Museum, which could use the KMS key to create it’s own S3 bucket using Terraform/awscli.
Terraform is great for creating infrastructure, but using it to install Helm charts should be an anti-pattern:
helm lintbecause templating needs to be done through Terraform.
Sugarkube’s sample kapps use Terraform for what it’s good for – managing infrastructure, e.g. creating buckets, Route53 entries, load balancers, etc.
This means that it becomes possible to easily version your Terraform configs alongside the chart that needs them. So if your Wordpress chart changes from being backed by Postgres on an EC2 to using RDS, the point at which that change happens is tightly bound to actually creating the RDS instance. Since Sugarkube’s kapps create the infrastructure they need, and manifests allow multiple kapps to be versioned alongside each other, you could either update your Wordpress kapp to create an RDS instance just for its own use, or create it in a shared kapp for multiple Wordpress instances to use.
No. Our examples provide extra features if you do use Helm & Terraform though. For example environment-specific
values-<env>.yaml files can automatically be passed as parameters to
helm. But these are extra benefits, not requirements to use Helm or Terraform, and they’re configurable anyway.
Sugarkube is really several things:
There’s no hard dependency on Kubernetes. If you can install something with scripts, you should be able to convert it to a kapp to be installed by Sugarkube. For now we’re focussing on the Kubernetes usecase but if you’re adventurous you should be able to use it with other tech stacks.
Yes. Sugarkube doesn’t need to manage clusters. If you’ve already got existing clusters or a process for creating them you can continue to use them and just use Sugarkube to install kapps. But if you haven’t got existing clusters, Sugarkube can create clusters for you as well, but it’s simply a convenience.