The way we build SUSE Cloud Application Platform

If you’re reading this you probably know what PaaS and Cloud Foundry are.

You probably also know that SUSE has its own flavor of Cloud Foundry. But what’s different in this flavor of ours?

First, let me mention that we haven’t removed any functionality – we support everything that upstream does.

Everything that’s supposed to be there is there.

We’ve added a couple of things for your benefit, though: SUSE stacks and the Universal Service Broker. But the real difference lies in how you operate it. Upstream Cloud Foundry is made to run on good old VMs. It’s entwined with a great toolchain called BOSH. You’ve likely heard of this too.

BOSH does two things. It helps developers describe how to run complex distributed applications, and it offers runtime components that deploy and manage software on top of an IaaS.

Ok, but what’s Kubernetes?

Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.

Yeah, that sounds interesting. And it’s getting more popular every day. So why don’t we run Cloud Foundry on top of that?

We do! That’s what fissile is for. It makes Cloud Foundry run on top of Kubernetes using Helm, the package manager for Kubernetes.

Our goal is to make it easy to deploy Cloud Foundry anywhere you can find a Kubernetes.

Fissile is a build tool we’ve created that can take all of the BOSH descriptions of running Cloud Foundry, and convert them into docker images and Helm charts.

It’s really a companion to BOSH that extends Cloud Foundry’s reach to the world of Kubernetes. It all happens in a few steps, by leveraging the structure that’s already there: stemcells, packages and jobs.

First, we create a base docker image from the same sources as BOSH VM images. We use that as the base docker layer for all images that make up SUSE Cloud Foundry. We also use it to compile packages. Once that happens, they all become part of images as another docker layer. And the final layer of this fissile cake are job scripts and configuration files. The images created by fissile can be deployed however you like.

If you set all environment variables you can get everything running with `docker run` if you want to. It might take you a while because you need to set quite a few of them, but each role can be properly run on its own. The point is that it opens up the range of deployment options – the learning curve for working with the BOSH runtime is removed.

So running things manually is technically possible, but that will require you to write a bunch of scripts, create certificates manually, figure out DNS, etc. etc. Of course, we wanted to wrap all that in something easier to manage, therefore we baked the capability to generate Helm charts into fissile.

Fissile is opinionated on how it creates these helm charts. As mentioned before, we shifted everything to environment variables. Every container renders configuration files using information gathered from the environment. And with Helm on top of that, everything is exposed in a few sections:

• `env` (configuration values that alter the behavior of Cloud Foundry)
• `secrets` (passwords and certificates)
• `sizing` (controls how many copies of each role you want to run, and how big you want them to be)
• `kube` (kubernetes specific values, like what type of storage class to use)

All secrets are managed by a special job that can generate passwords and certs if the user doesn’t specify them. Also, we don’t expose every single setting Cloud Foundry has. We just expose what the operator cares about. The internals are managed automatically.

Using fissile gives us the tools we need to deliver Cloud Foundry in a package that makes deployment easier for our customers. It allows us to easily deliver compiled bits, and it makes configuration simpler, and it all comes from the same sources as upstream Cloud Foundry.

This is just the beginning. We’re constantly improving the way we generate the images. Our goal is to make Cloud Foundry deployment management effortless. Another blog post coming up is going to talk about a proposal to add native containerization capabilities to BOSH, that was made to the Cloud Foundry Foundation in collaboration with IBM and SAP.

So stay tuned.. And thanks for reading!