Docker Hub and the aging population
Public images on Docker Hub have a date when they were last updated. As a developer using containers you might create an image and then never touch it again, or you might be constantly rebuilding the image with new features.
Here’s the distribution over time showing when all the current public container images were last updated.
The mysteries of 4Q2015
This does beg an obvious question: what the heck happened in October and November 2015? Around 60,000 images were updated back then, almost a year ago, and have not been touched since.
Hello World
One theory is that this could have been a huge cohort of developers trying Docker for the first time.
But there are only (only!) 3,175 public images on Docker Hub called hello-world (or something very similar). So that doesn’t explain that big chunk of seemingly abandoned images. Perhaps a lot of developers using containers have been more imaginative about their early image names, and we’ve missed them in our search.
Missing containers — found in Amazon?
It could just be a coincidence, but December 2015 was when Amazon’s container registry service (ECR) became generally available.
Does this really explain that bump in the graph? Did thousands of developers stop using free, public repository hosting on Docker Hub and move to ECR, where you have to pay for storage? Even if S3 storage pricing is reasonably cheap, it’s still not free.
Have you got images you stopped updating on Docker Hub at the tail end of 2015? What happened?
Automated builds
It doesn’t seem to make much difference whether an image is being built automatically or not — there’s roughly the same proportion of automated and non-automated builds throughout the distribution.
Does it matter how old an image is?
Given that it’s free to store public images on Docker Hub, as the repo maintainer there is no incentive to delete old images that you’re no longer using. And it’s also very possible that many images are perfectly stable, and don’t need changes for months at a time.
But if you’re consuming images it’s another matter. By definition, an image that hasn’t changed after a security patch was released cannot contain that security patch.
If you’re using a public image based on Alpine, say, and it was built using the 3.3 version, you can see that it contains some currently-known vulnerabilities.
You can use MicroBadger to see when an image — in this case the version of Alpine tagged 3.4 — was built.
If you’re using a public image based on Alpine that was built before 23rd June, it doesn’t have that update that fixes the vulnerability identified in 3.3.
So yes, age does matter. Whether you go the full Logan’s Run and delete your older images, well that’s up to you!
If you liked this article, please hit the Recommend button below so that others might be more likely to find it. And if you’re using containers, you should definitely check out MicroBadger to explore image metadata.
Follow Microscaling Systems on Twitter
