Sugarkube is both an orchestrator and software release system targetting Kubernetes clusters. It allows you to create and destroy ephemeral clusters. Code for your applications can contain configs for creating infrastructure allowing you to version them together as a single unit. This means the releasable artefact is your application code and the code to create the infrastructure it needs. If you embrace ephemeral clusters, the deliverable unit really becomes the entire cluster itself.
Many other tools only create either infrastructure (Kubernetes, Terraform, CloudFormation, etc.) or release your applications (Helm, tarballs, whatever). This means you need some way of coordinating your application changes with the infrastructure they depend on, which can be complicated and error-prone. You also need a way of preparing a cloud account first, e.g. to create DNS zones, S3 buckets, VPNs, etc.
After defining which of your applications depend on which others Sugarkube constructs a dependency graph which allows it to install or delete your applications in the correct order. So, for example, if your Wordpress sites depend on databases and a load balancer, Sugarkube can make sure they’re created before the Wordpress sites are installed, and deleted after the Wordpress sites have been deleted when tearing down the cluster. Sugarkube can also pass the hostnames of the databases to the Wordpress sites. Here’s what the dependencies might look like:
This is actually the dependency graph for our example web cluster. You can see how easy it is to run for yourself by following our tutorials.
Versioning your applications and infrastructure together is incredibly powerful. This idea means Sugarkube can:
All of the above make it simple to start working on new features without wasting time recreating infrastructure that your applications need. Adopting Sugarkube for a project will also lay extensive foundations for future scaling, both technologically and for when your team grows.
A key feature that makes Sugarkube so flexible is that it allows you to parameterise your deployments differently depending on the target cloud account or purpose of the cluster. So for example you can easily configure Sugarkube to use lots of large instances for your cluster in production, but only a few smaller ones for dev environments. Or you could create a small database and install fixture data into it in dev environments while using your real database in production.
If you want to you can define your configuration hierarchically. This means you could create default configurations and progressively override or replace certain parts at more specific levels. To give a concrete example, a directory structure such as below would allow you to override and tailor your configurations in several ways:
- providers - aws - dev - kops.yaml # extra config just for kops clusters - dev1.yaml # configs just for the 'dev1' cluster - eu-west-1.yaml # configs for all dev clusters in eu-west-1 - test - kops.yaml # extra config just for test kops clusters kops.yaml # default kops config
Sugarkube will search for files with various basenames at each level in your directory hierarchy, merging them together depending on the parameters of your target cluster. In addition, values in these config files can contain variables. Some practical applications of this are:
Sugarkube has been designed to for maximum portability. It should be pretty seamless to develop on a local Minikube cluster and then deploy onto a cloud-based/hosted cluster. With a bit more effort it becomes possible to migrate applications between cloud providers as well allowing you to run in a multi-cloud setup.
If you work with Kubernetes clusters Sugarkube provides additional features. As already mentioned, it can launch Kubernetes clusters and can do so with several provisioners (for now EKS, Kops and Minikube) and then configure them. For example it can patch Kops YAML configs before triggering an update to apply those changes. This makes it a useful tool for administering long-lived Kubernetes clusters when ephemeral clusters aren’t an option. However its main benefit is that it allows you to create a cluster and install your applications (with dependent infrastructure) with almost a single command.
Although technically you don’t have to use Kubernetes, Helm and Terraform with Sugarkube, for the sake of simplicity we’ve made an assumption that you will be, at least for now. This allows us to simplify the problem-space and get something working in a more predictable setup instead of trying to please everyone immediately. So if you choose not to use K8s, Helm and Terraform you may find a few things don’t work as expected. Please open an issue on Github to tell us about those scenarios if you run into them so we can track them.
As an orchestrator Sugarkube wraps other tools you’re probably already familiar with. It delegates to eksctl/kops/minikube for provisioning clusters, and our sample project and default configuration file assume Helm and Terraform. However you aren’t forced to use any particular set of tools or technologies. Sugarkube will work with on-premise, legacy systems and infrastructure provided it’s scriptable, and also with any programming language. You can adopt it bit-by-bit while you get used to it, and migrate more to it (or drop it) as you wish.