Does Sugarkube depend on containers?

No. Sugarkube just runs commands. It’s up to you what they do.

How does it compare to Helm?

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 x.y.z.

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.

How does it compare to Terraform?

Terraform is great for creating infrastructure, but using it to install Helm charts should be an anti-pattern:

  • Local development becomes a pain because you need to continually change the CLI args to make it reinstall a chart since it has no other way of knowing whether a chart has changed and needs reinstalling.
  • You lose the ability to run helm lint because templating needs to be done through Terraform.
  • You often end up with lots of related repositories that are a pain to version together if you want to split out your values from your terraform code/modules.
  • It can be difficult to pass outputs from one application to another, especially if you want the flexibility to only install subsets of your applications.
  • There are some things the AWS API doesn’t conveniently let you do, so therefore are difficult with 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.

Do I have to use Helm and/or Terraform?

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.

What if I don’t use Kubernetes?

Sugarkube is really several things:

  • A way of executing commands depending on whether you want to install something or delete it
  • A system for defining dependencies between applications
  • A config management system that allows settings to be overridden depending on the target runtime environment/cluster

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.

Is Sugarkube compatible with existing clusters?

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.