That’s not my image!
No one likes spam, obviously, but the rise of pretty decent spam filtering (thank you Gmail!) means that folks are perhaps a little less wary than they used to be about putting their email address on the Internet.
If you’re publishing code on GitHub you have the option to share your email address there, presumably so that it’s easier for people to get in touch and ask questions / make business proposals / offer jobs. And similarly, Docker images support a MAINTAINER directive so that you can add your email address to a container image. It’s free-form text, so you could add your name, email address, phone number – anything you like. Our analysis using MicroBadger shows that around 1/3 of public images on Docker Hub have a MAINTAINER including an email address.
So, you add your address in the MAINTAINER directive for your Dockerfile, and if anyone has any questions or comments about your image, they know how to reach you.
You push your code to GitHub, including the Dockerfile. Other folks build on your good work, and create their own version of the image, using your Dockerfile.
Inadvertent reuse
The trouble is, if they don’t update the MAINTAINER directive in the Dockerfile with their own address, their image will use yours. At any point you might find yourself getting emails about a repo you’ve never heard of. I’ve sent a couple of messages myself to folks about an image and received the simple response: “That’s not my image”.
Moving to Labels — better or worse?
The MAINTAINER directive may not be long for this world, and I’d agree that there’s no great need for a special term for this when general purpose labels exist that can be used more powerfully. However, there is potentially a bigger problem, because labels are inherited from a base image to any images that are built on top of it. People might end up re-using your metadata not just by rebuilding based on your Dockerfile, but also simply by using your image in the FROM directive of their own Dockerfile.
There are other cases where labels don’t really make sense to be inherited: you don’t want to inherit, say, the build date from a base image that was built months ago. Labels are key-value pairs so this can be mitigated somewhat by using Label Schema — if the Dockerfile for the child image uses the same key as the parent, it will overwrite the parent’s value. But of course this only works if the child image’s Dockerfile has a label with the same key.
The case for non-inherited labels
One improvement might be to allow for build-time labels that can’t be inherited from one image to another. This breaks down into two parts — allowing for build-time labels, and preventing inheritance.
Adding labels at build time is supported today — docker build command already supports the addition of labels as command-line arguments, so this is totally scriptable. You can’t, as far as I can tell, add a MAINTAINER at the command line, but you could do this and add labels through Gareth Rushgrove’s Dockerfile pre-processing approach.
The part that isn’t supported right now is the ability to prevent some metadata from being inherited. This could be done by designating some set of Label Schema as non-inheritable, and/or marking particular labels added at build time as non-inheritable. This might require a bit of extra manipulation of the config json stored for an image, so it would need support from Docker and other container providers. Wdyt? Would love your thoughts!
Photo credit: sweet_vengeance on Flickr
If you liked this article, please hit the Recommend button below. You might also enjoy Using Docker Tags to Mess With People’s Minds.
Follow Microscaling Systems on Twitter
