Use labels on your Docker images
Using labels on your images is a handy way to develop better build automations on your Docker images
At first I started using Docker just to develop as a handier alternative to my previous setup with Vagrant. It didn't took longer for me to want to use my containers is production.
It was kind of easy to get my containers running in production using Kubernetes. After that I wanted it to be build by my CI. Again it wasn't hard at all.
I wanted to reuse the deploy I created for all (or at least mostly) of my images but then I started to wonder how I could avoid having to change it depending on the technology that I was building.
It would be nice if I could store within the image some data like what to do if testing or what should I run once before my image actually gets deployed to production (like running rake db:migrate if it's a Rails application).
At first I thought about having a defined files structure inside the image like the /etc/rc.d structure but even that it does the job, it doesn't seem right.
I then considered using labels as they would be easier for a real Docker based CI to use.
Labels: a quick'n'dirty guide
Storing metadata on your image
Docker offers support to add labels into images as a way to add custom metadata on them.
The label syntax on your Dockerfile is as follows:
LABEL <key>=<value> <key>=<value> <key>=<value> …Using it we can store our data on it like:
LABEL multi.label1="value1" \
multi.label2="value2" \
other="value3"Retrieving your metadata from your image
To do so you you use the inspect command.
docker inspect \
--format "{{ index .Config.Labels \"multi.label2\"}}"
<image-name>#=> value2
It was handy and would let me to develop a build/deploy without having to deal with the image specificities on the script. It was all about reading the proper labels.
Then I started to consider: isn't there a standard to allow everybody to use the same set of labels to allow that an image could be manipulated by any system if the proper standard were followed?
IT professionals have a responsibility to understand the use of standards — Tim Berners-Lee
Label Schema
Well, as usual, it's kind of hard not to find something already on progress on the internet 😄
I found a draft of a label schema specification at label-schema.org that is dealing exactly with that: to try to create a common schema for the common needs a developer may need.
Docker documentation had already on it's key recommendations a rule of adding a namespace to avoid collision between keys so they created the universal namespace org.label-schema.
Under this namespace you'll see a list of keys handy to carry on important metadata, such as:
- vcs-ref: Identifier for the version of the source code from which this image was built (for git it would be a SHA).
- vcs-url: URL for the source code under version control from which this container image was built.
- docker.cmd: How to run a container based on the image under the Docker runtime.
- docker.cmd.test: How to run the bundled test-suite for the image under the Docker runtime.
- docker.params: applicable environment variables for the Docker runtime.
- many more…
For a comprehensive list look at label-schema build time labels specification.
What about our specific needs?
I'll stick with my previous Rails bound example. Before deploying my new image to production I must run rake db:migrate. So far the label-schema.org hasn't covered it.
This is a peculiar case that I'd rather to stick with the standards but there are none so far.
For now I'd create a custom metadata for while we don't get a standard way, pretty much on this way:
com.my-company.pre-deploy="rake db:migrate"com.my-company.post-deploy=""com.my-company.rollback="rake db:rollback"
Contributing to build up a good standard
It's always nice to contribute to the creation of a standard as it brings new perspectives on how we'll solve our problems.
I'd also propose a change on their issues page on GitHub. The project is fresh new and there is a good chance to add something form ourselves to it.
It's always better to help an ongoing effort or, well, you know…
