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:
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
mkdir ~/score-getting-started ; cd ~/score-getting-started
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.
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
score-compose run -f frontend.score.yaml -o frontend.compose.yaml
score-compose run -f backend.score.yaml -o backend.compose.yaml --env-file .env
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:
docker-compose -f db.compose.yaml -f backend.compose.yaml -f frontend.compose.yaml --env-file .env up
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:
echo ------- Deployments ----------
kubectl get deploy
echo --------- Services -----------
kubectl get svc
echo --------- Pods ---------------
kubectl get pods
echo --------- Backend Pod Logs ----------
echo If you dont see any logs, run this command again
kubectl logs -l app.kubernetes.io/name=backend --tail=4
Your output should be similar to this:
helm uninstall backend db frontend
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.