Docker announced this week they’d hit 6 billion pulls on Docker Hub. They hit 5 billion in August so this is fast growth. To celebrate, we’ve been looking at the latest trends in public image creation and metadata on Docker Hub.

Counts?

As of early this week, there were just under 400K public images on Docker Hub (376663 to be exact). This is growing by roughly 4–5K each week as new images are created.

How Many Docker Hub Public Images have Labels?

We’re very interested in container Labels because we believe metadata is both best practise and vital to an orchestrated future for containers. Labels are Docker’s recommended way to provide metadata.

So what are the trends here? It’s still early days:

8.5% of public images, in total, have a Label. But many of these Labels are incorrect (see below).

91.5% of public images provide no Label metadata.

CentOS Labels and a Good Example of Bad Practise

3.9% of the public images on Docker Hub only have a label because they picked up the labels of their CentOS base image. Images built from a base image inherit that base image’s labels, so CentOS’s labels are inherited by any image based on it.

You can inspect the CentOS image labels here on Microbadger. In summary, CentOS’s images are labelled with: build-date, license, name and vendor

Well done CentOS for using Labels! This is certainly a example of good practise from them.

However…

That means that as a user of the CentOS image, if you don’t overwrite those inherited labels your image is going to be wrongly labelled with CentOS’s build-date, license, name and vendor. Really, that’s worse that not providing any metadata at all. Many image creators are not aware of this (in fact, clearly the vast majority of CentOS base image users). But it is easy to fix! The correct practise for image users is to overwrite inherited labels in your Dockerfile by re-specifying them.

Top 100 Labels

The most popular Labels in use today are: name, vendor, license and build-date, mostly because of CentOS inheritance.

Unfortunately, there are quite a few variants of these (see below). We’re part of a community trying to agree conventions for label naming at label-schema.org following the well thought-out Docker guidelines on clear, namespaced Label definitions.

The top 100 labels in use on public images on Docker Hub are currently:

╔══════╦════════════════════════════════════════════╦═══════╗

║ rank ║ label ║ count ║

╠══════╬════════════════════════════════════════════╬═══════╣

║ 1 ║ name ║ 15585 ║

║ 2 ║ vendor ║ 15508 ║

║ 3 ║ license ║ 15228 ║

║ 4 ║ build-date ║ 14668 ║

║ 5 ║ Vendor ║ 4886 ║

║ 6 ║ License ║ 3947 ║

║ 7 ║ kolla_version ║ 3811 ║

║ 8 ║ com.docker.compose.container-number ║ 1577 ║

║ 9 ║ com.docker.compose.service ║ 1577 ║

║ 10 ║ com.docker.compose.oneoff ║ 1577 ║

║ 11 ║ com.docker.compose.version ║ 1577 ║

║ 12 ║ com.docker.compose.project ║ 1571 ║

║ 13 ║ com.docker.compose.config-hash ║ 1533 ║

║ 14 ║ io.resin.architecture ║ 1512 ║

║ 15 ║ Description ║ 1454 ║

║ 16 ║ io.resin.qemu.version ║ 1431 ║

║ 17 ║ Version ║ 1409 ║

║ 18 ║ io.resin.device-type ║ 1406 ║

║ 19 ║ version ║ 1327 ║

║ 20 ║ description ║ 1147 ║

║ 21 ║ io.k8s.display-name ║ 966 ║

║ 22 ║ io.k8s.description ║ 945 ║

║ 23 ║ io.openshift.tags ║ 803 ║

║ 24 ║ io.openshift.s2i.scripts-url ║ 775 ║

║ 25 ║ io.openshift.expose-services ║ 728 ║

║ 26 ║ com.nvidia.cuda.version ║ 670 ║

║ 27 ║ com.nvidia.volumes.needed ║ 630 ║

║ 28 ║ io.s2i.scripts-url ║ 586 ║

║ 29 ║ com.nvidia.cudnn.version ║ 541 ║

║ 30 ║ io.openshift.builder-base-version ║ 461 ║

║ 31 ║ Name ║ 381 ║

║ 32 ║ Release ║ 377 ║

║ 33 ║ Architecture ║ 347 ║

║ 34 ║ Build_Host ║ 332 ║

║ 35 ║ io.openshift.builder-version ║ 322 ║

║ 36 ║ BZComponent ║ 322 ║

║ 37 ║ RUN ║ 319 ║

║ 38 ║ Authoritative_Registry ║ 316 ║

║ 39 ║ architecture ║ 289 ║

║ 40 ║ org.label-schema.vcs-url ║ 262 ║

║ 41 ║ vcs-type ║ 254 ║

║ 42 ║ vcs-ref ║ 254 ║

║ 43 ║ INSTALL ║ 213 ║

║ 44 ║ org.label-schema.vcs-ref ║ 209 ║

║ 45 ║ org.label-schema.build-date ║ 195 ║

║ 46 ║ org.label-schema.name ║ 192 ║

║ 47 ║ io.codefresh.repo.sha ║ 183 ║

║ 48 ║ io.codefresh.repo.branch ║ 183 ║

║ 49 ║ io.codefresh.repo.owner ║ 183 ║

║ 50 ║ io.codefresh.repo.name ║ 183 ║

║ 51 ║ io.codefresh.repo.type ║ 179 ║

║ 52 ║ io.codefresh.repo.hash ║ 179 ║

║ 53 ║ url ║ 175 ║

║ 54 ║ STOP ║ 157 ║

║ 55 ║ vcs-url ║ 151 ║

║ 56 ║ org.label-schema.url ║ 135 ║

║ 57 ║ io.openshift.s2i.destination ║ 131 ║

║ 58 ║ com.docker.swarm.id ║ 129 ║

║ 59 ║ org.label-schema.vcs-type ║ 126 ║

║ 60 ║ org.label-schema.docker.dockerfile ║ 125 ║

║ 61 ║ org.label-schema.license ║ 122 ║

║ 62 ║ org.jboss.deployments-dir ║ 112 ║

║ 63 ║ io.projectatomic.nulecule.atomicappversion ║ 107 ║

║ 64 ║ node_mission ║ 106 ║

║ 65 ║ io.projectatomic.nulecule.specversion ║ 104 ║

║ 66 ║ demo ║ 101 ║

║ 67 ║ io.projectatomic.nulecule.providers ║ 99 ║

║ 68 ║ io.webdevops.layout ║ 98 ║

║ 69 ║ io.webdevops.version ║ 98 ║

║ 70 ║ distribution-scope ║ 95 ║

║ 71 ║ org.label-schema.version ║ 91 ║

║ 72 ║ io.openshift.generate.job ║ 90 ║

║ 73 ║ io.openshift.generate.token.as ║ 90 ║

║ 74 ║ arch ║ 89 ║

║ 75 ║ che:server:8080:ref ║ 85 ║

║ 76 ║ application ║ 85 ║

║ 77 ║ org.label-schema.schema-version ║ 85 ║

║ 78 ║ che:server:8080:protocol ║ 84 ║

║ 79 ║ che:server:8000:protocol ║ 84 ║

║ 80 ║ com.redhat.deployments-dir ║ 83 ║

║ 81 ║ che:server:8000:ref ║ 83 ║

║ 82 ║ fullVersion ║ 81 ║

║ 83 ║ io.rancher.container.uuid ║ 79 ║

║ 84 ║ summary ║ 78 ║

║ 85 ║ io.openshift.s2i.build.source-location ║ 77 ║

║ 86 ║ io.openshift.s2i.build.image ║ 77 ║

║ 87 ║ io.rancher.container.ip ║ 77 ║

║ 88 ║ org.label-schema.vendor ║ 74 ║

║ 89 ║ io.fabric8.s2i.version.jolokia ║ 70 ║

║ 90 ║ io.fabric8.s2i.version.maven ║ 70 ║

║ 91 ║ com.redhat.dev-mode ║ 67 ║

║ 92 ║ com.redhat.dev-mode.port ║ 67 ║

║ 93 ║ io.rancher.container.name ║ 66 ║

║ 94 ║ io.openshift.build.commit.author ║ 65 ║

║ 95 ║ io.openshift.s2i.build.commit.author ║ 65 ║

║ 96 ║ caddy_version ║ 63 ║

║ 97 ║ Build ║ 62 ║

║ 98 ║ org.label-schema.description ║ 62 ║

║ 99 ║ distro ║ 62 ║

║ 100 ║ nodeGroup ║ 60 ║

╚══════╩════════════════════════════════════════════╩═══════╝

What to do?

If you believe in a more secure, resilient, eco-friendly orchestrated future for the data centre

get labelling!

check the current labels on your images and make sure they are correct and that you’re not accidentally inheriting something that isn’t right for your image. You can overwrite any inherited labels in your Dockerfile by just re-specifying them.

Please hit the Recommend button below if you found this article interesting or helpful, so that others might be more likely to find it.

Check out MicroBadger to explore image metadata, and follow Microscaling Systems on Twitter.