Last week at HashiConfEU our own Anne Currie unveiled the MVP of MicroBadger, a tool we’ve been working on to make managing containers easier and safer. In this post we’ll explain the motivation behind MicroBadger; show why it is already gaining support from influential people in the container ecosystem, and of course, we’ll explain how to use it.
As the number of Docker images in your system increases certain questions become hard to answer.
What is in those images? How can I get back to the exact commit that created this image? How can I tell how many of the containers that I’m running come from an image containing a library with a known bug or security flaw? In fact, do I even know which of the container images I’ve built are running in my cluster?
In 2015 Sonatype released their ‘State of the Software Supply Chain’ which highlighted some key areas that were not receiving enough attention from the Docker community, the bottom line: we rarely have a good idea about what we are actually running. While this may be manageable for development workloads where developers have an intimate knowledge of what they are working on and the risk is lower, it becomes a ticking time bomb when scaled up for production.
The issue becomes especially prevalent issue at companies running microservice architectures with quick development cycles. They may have hundreds of different services being developed, with each service’s respective CI pipeline pushing out many new version per day. Bitnami captured this well in a recent TheNewStack article: the “...lifecycle and change and configuration management technologies and habits that evolved over 5-10 years of managing virtual infrastructure will need to be re-examined.”
Gareth Rushgrove of Puppet Labs has been talking about this problem for some time too and uses the analogy of a real shipping container’s manifest which states exactly what is inside the container.
With Docker this manifest becomes image metadata and since Docker 1.6 there has been a perfectly good method for expressing such metadata; Docker labels. Unfortunately an informal survey conducted in late 2015 concluded that fewer than 20% of images contain any labels at all. With the remaining 80% it is very difficult to figure out exactly what you’re running when something goes wrong.
What does MicroBadger do right now?
Have you ever found an image on the Docker Hub and wondered what code it was built from? Or tried to locate the Docker image for a source code repo?
By labelling containers with the source code details, MicroBadger makes it easy to move with confidence between source code repository and image hub.
Get badges for your code & image. MicroBadger supplies badges for your GitHub Readme file and Docker Hub notes, so that anyone can easily jump from your source code to Docker image and vice versa.
There are three steps to getting your badges:
- Push the image to Docker Hub so that it’s publicly available
- Look up the image on MicroBadger
If your image is labelled correctly you’ll get markdown that you can then copy-and-paste to the GitHub readme and into the Docker Hub notes.
Some public images such as puppet/puppetserver and centos already include metadata, so they serve as an good basis for exploration.
With MicroBadger we would like to encourage the use of Docker labels by providing a simple way to inspect them. Of course it will require more than just Docker labels to understand a software supply chain, but we chose to start with labels and will be moving to other areas in later releases such as inspecting the Dockerfile and following library dependencies from there.
How can I get involved?
We would like you to label your images, use our badges and give us some feedback. Check out these examples where people are already using labels, badges and metadata: