MicroBadger and the Awesome Power of Container Labels
Containers have the power to change infrastructure architecture, making it more secure and more energy efficient. This is because containerized applications can be started, stopped or juggled from machine to machine in seconds — far faster than applications can be moved on VMs or bare metal. That speed opens up the world to intelligent container-aware tools that can control what’s running in a data center in near real time.
Combined with clever tooling, containers could help make data centers less static and more like an organic body: re-assigning resources or repelling threats as and when required.
But for this vision to come about, those clever tools of the future need information. They need to know things like: is a particular containerized image mission critical? Does it contain a security flaw? Can it be safely stopped? Who should be paged if it crashes?
Image Conscious? Try Labels
The good news is Docker containers have a flexible mechanism for allowing image creators to specify information: labels. Labels were introduced in Docker 1.6 and are a straightforward way of providing metadata for a container image, such as who maintains the image or what license it‘s under. Label metadata can be simply specified as arbitrary key/value pairs.
That’s great. However, the bad news comes in two flavors. Firstly, labels aren’t very commonly used. According to Gareth Rushgrove of PuppetLabs it looks like less than 20 percent of images have labels. Our analysis of DockerHub suggests the real figure may be even lower. That’s a shame because without any kind of metadata a container image is a bit of a black box.
The second problem is that currently there’s no standard schema for labels. Docker encourages the sensible use of namespacing (com.thenewstack.mylabel) for label names but then they have left developers to their own devices. This means when people do start using them, labels will end up being inconsistent or application-specific and hence less useful. Some good work has been done here by Red Hat on Project Atomic, and by OpenShift and by Kubernetes but the latter are for application-specific rather than generic label definitions. But more is needed.
We think getting a minimal agreed label schema is vital to fully exploiting containers as operational and DevOps technology. So, building on the work by Docker, Red Hat and others were working with a number of vendors on a community project called label-schema.org. The project aims to define a common set of useful labels that image creators can easily apply via Dockerfiles. In addition, we’re working to get standardized labeling into the next generation of container build tools.
I Don’t Want to Badger You, But…
In order to encourage developers to start with labeling, we’ve built MicroBadger.com, where you can see all the labels for any public image on DockerHub and find out useful information like who maintains it, how big it is and when it was built. For example the microscaling image.
The purpose of MicroBadger is to encourage image creators to use labels, make those labels consistent and get useful Metadata badges that, for example, link a DockerHub image to the GitHub code it was built from.
By labeling containers with the source code details, MicroBadger makes it easy to move with confidence between source code repository and image hub.
We think everyone should get badges for doing the right thing so we encourage developers to define and use standard metadata on their container images and use MicroBadger badges to spread the word. To find out more about labels, watch my talk at SoftwareCircus in Amsterdam August 31 – September 2, or please drop in.
Docker and Red Hat OpenShift are sponsors of The New Stack.
Feature image: Software Circus.
