When building systems that integrate with our API, sometimes you need to store some configuration or state. It’s natural to want to store this somewhere in our API, since you already have access to it, it’s private and highly available! Our Orbit storage system is good for storing larger blobs of data, but for small metadata we’ve seen customers storing JSON in description fields, or packing data into name fields even!
So we’ve added a new resource to our API to help: ConfigMaps. A ConfigMap is simply a resource containing a number of arbitrary keys and values that can be stored and retrieved using our API. Nothing fancy. It’s very similar to the Kubernetes ConfigMap API object (we stole the name and the general structure, but it’s not a complete implementation).
For example, we’re using a ConfigMap for our Kubernetes auto-scaling system, where the user sets the configuration using Terraform but the autoscaler can run at any time and doesn’t have access to the Terraform manifests. So our manifests store the autoscaling configuration (such as the server specifications, the maximum number of servers to build, and even the pre-generated userdata script) in a ConfigMap and the autoscaler reads that whenever it needs to make a scaling decision.
But ConfigMaps aren’t a general purpose database, they’re just for configuration or small amounts of state. To reflect this, each ConfigMap is limited to 1MB and accounts currently have an overall 10MB quotas.
ConfigMaps are now available in our RESTful API.
{
"id" : "cfg-xxxxx",
"name" : "example",
"resource_type" : "config_map",
"url" : "https://api.gb1.brightbox.com/1.0/config_maps/"
"data" : {
"db_server" : "1.2.3.4",
"debug" : "false",
"max" : 45,
"min" : 12
},
}
We’ve also added support to our Terraform provider. You can define ConfigMaps like this:
resource "brightbox_config_map" "example" {
name = "example"
data = {
"db_server": "1.2.3.4",
"debug": "false",
"max": 45,
"min": 12
}
}
Our immediate use case was within Terraform, but We’ll be adding support to our other API clients, such as Fog, our CLI and eventually our GUI too!
We’ve kept the ConfigMap implementation simple for now, but we have a few ideas about how we’ll use this in future, including for server templates, userdata sources and even support for mounting them into cloud server filesystems, much like Kubernetes ConfigMaps can be mounted into pods.