Get started with Score: Docker Compose to Helm
In this tutorial you will learn how to get started with Score, a platform-agnostic, container-based workload specification. We will cover the creation of two Score Specification YAML files and how we can translate them to Helm values files and Docker Compose.
Score is an open source, platform-agnostic, container-based workload specification. This means you can define your workload once with the Score Specification and then use a Score Implementation CLI to translate it to multiple platforms, such as Kubernetes (as a Helm values file), Google Cloud Run, or Docker Compose. The aim of this project is to reduce toil and cognitive load of developers by only having to define a single YAML that works across multiple platforms.
Score does not intend to be a fully featured YAML replacement for those platforms, it only aims to define workloads that can be combined with more advanced YAML configurations that an infrastructure team would provide to developers in an organization.
This tutorial will cover the creation of two Score Specification YAML files and how we can translate them to Helm values files and Docker Compose.
This tutorial requires you to have the following tools installed:
- Docker Compose
- A Kubernetes cluster to experiment on. If you want to do this locally we recommend Kind
- kubectl connected to your Kubernetes cluster of choice
- Install score-helm and score-compose
Two Workloads with Score Spec
In this scenario, we will be first donning our developer hat and creating two Score spec YAML files for the following workloads:
- A mock <span class="c">backend workload</span> with <span class="c">postgres:alpine</span> image that connects to a <span class="c">database resource</span> and to a <span class="c">frontend workload</span>.
- A mock <span class="c">frontend workload</span> with <span class="c">nginx:alpine</span> image.
We will then don our infrastructure engineer hat and create the following resource:
- A <span class="c">db resource</span> compose file and Helm values file with <span class="c">postgres:alpine</span> to mimic a database.
Don’t forget to ensure you have all the pre-requisites before you follow these steps.
1. Create a folder
2. Create <span class="c">backend.score.yaml</span>
- This is a mock <span class="c">backend</span> with image <span class="c">postgres:alpine</span> that connects to the database resource and a frontend workload to demonstrate connectivity and dependency of resources.
- The variable values are mostly derived from placeholders that refer to resource data. Resources also explicitly define your workload dependencies, but they can also be used to define environment variable values as shown by the <span class="c">GREETING_NAME</span> variable.
You may be thinking, why should I go this long winded way to provide values to my environment variables via resource placeholders? Why don’t I just do it directly? The answer is that Score is designed with dynamic configuration management in mind, meaning that values can be injected in the target environment without needing to change your Score file for every environment.
3. Create file <span class="c">frontend.score.yaml</span>
4. Donning the infrastructure engineer hat, create the <span class="c">db.compose.yaml</span> - this is a compose YAML, not Score!
Technically, we could also define this in Score as it is a simple workload with a volume to mimic our database infrastructure, but we wanted to highlight here that Score is only to be used with microservice workloads that are typically the purview of developer activities. Infrastructure engineers would define and/or provision any other infrastructure that’s required, whether with Compose files, Terraform or whatever.
Therefore, Score is not intended to be a full feature replacement of using Compose or Helm directly, just a way for developers to define their workload specifications and be able to translate that to multiple platforms.
5. Translate Score files to Compose files
This command will translate your Score files and write the resulting output to Compose files. The <span class="c">--env-file</span> flag is used to write a <span class="c">.env</span> file that can be used by <span class="c">docker-compose</span>.
Let’s look at the resulting files and explain them a little bit:
The environment variables have been defaulted to the values you defined in your services earlier, but they also have been written to an <span class="c">.env</span> file below. A developer could edit the variables in the <span class="c">.env</span> file and add that to <span class="c">.gitignore</span> so passwords and other variables don’t get written to the repository.
6. Now that everything is in place, we can simply start our workloads like so:
We should get this output:
You can now control+c out of docker-compose and then clean up the volume and network with the following command:
We will be using the same Score files we created in the previous section to deploy our workload via Helm. Make sure you are still in the <span class="c">~/score-getting-started</span> folder.
If you did not do the score-compose section before this, you will need to at least set up your frontend and backend Score YAML files as described in step 2 and 3.
We will be assuming you already have <span class="c">kubectl</span> configured with a cluster. If not, you can use something like Kind to easily set one up, see pre-requisites above.
The <span class="c">score-helm</span> implementation outputs a values.yaml file to be used with Helm. It does not create a chart.
1. Create the helm values file that will be used by our db (infrastructure engineer persona)
2. Translate the Score files to Helm values files:
The above will create the following Helm values files: <span class="c">frontend-values.yaml</span>
3. Add the workload Helm repo
This Helm chart is a workload reference chart that can be adapted for any use case, find the source code here:
4. Install the three workloads using our three value files
5. Verify the installation
Your output should be similar to this:
That’s it! In this tutorial you have successfully:
- Defined a frontend and backend workload with Score as a developer using a single specification
- Defined a DB resource for both Helm and Compose as an infrastructure engineer
- Translated both workload Score specs to Helm and Compose
- Deployed all your workloads and infrastructure with both Compose and Helm
It is very important to understand that even though we have been using Score to translate YAML files to other YAML files we don’t just see it as a translation tool, we are well aware that there are tools for this already like Kompose that are far more fully featured.
You should look at Score as a way to define workloads, a spec that developers will use so that they don’t need to be concerned with all the nuts and bolts of infrastructure and can fully focus on development.
Help make Score a new standard
With Score, we’re not only aiming to speed up and advance application development for engineering teams but also foster focus, flow and joy for developers in their day to day work.
But we are still early. There’s a lot more work to be done both on the Score spec and especially the CLI implementations. So far, we released score-compose (Docker Compose) and score-helm (Helm), among others.
If you want a world with lower cognitive load on developers, less config drift or mismanagement, check out the repo, contribute and reach out. This is just the beginning — let’s build the future of development together.
The team behind Score
The idea for Score organically formed from looking at hundreds of delivery setups, across engineering orgs of all sizes (from startups to Fortune 100). We have all been involved in platform engineering and developer tooling for the past decade, in one way or another.Some of us built Internal Developer Platforms at the likes of Google, Apple or IBM, some come from the IaC side of things and played leading roles at companies like Hashicorp.
We all share the vision of developer and workload-centric development. We want to reduce cognitive load on developers and make sure engineers can spend their time coding and shipping features, instead of fighting config files.