Docker Images: not that special

It is really hard to refute the power of the container driven pipeline. The ability to move containers reduces risk, increases speed, and fosters the continuous delivery dream. Whether it is Docker or some future alternative, containers enable full-stack deployments, and build a lot of reliability into a delivery chain. That is if you can find a way to sustain it.

Docker adoption today rarely goes beyond the individual developer use cases. And while its benefits are clear for the enterprise there are several aspects that prevent it from being a production level solution. This is the result of thinking of Docker only in terms of its provision and release value. The oversight and management cannot be neglected. And one of the weakest areas for this is the creation, consumption and storage of the images.

CloudNative Summit

Getting a Docker image is easy. Via the Docker Hub a developer can have an entire stack in 5 mins. And the value of public registries is phenomenal. All you have to do is:

docker pull [imagename] docker run [imagename]

and you are done. The problem with the public registry is:

  • You do not necessarily know what is on those images.
  • Once you have an image what do you do with it?
  • Organizing images relies on memory not tools.
  • You can’t fully apply your organization’s governance.
  • And it does not directly integrate with your pipeline.

But the public registry can easily become a private registry. The most common being the paid version of Docker Hub, Google Containers, and manual installation of docker/distribution from GitHub.

Here is a table comparing the most popular private registries.

Docker Hub Google Registry Sonatype Nexus Artifactory Quay AWS
Search Limited Limited Full Full Full Limited


None None Full Full Limited Limited
Team Support None Limited Full Limited Limited Full
GUI Limited None Full Full Full None
Pipeline Integration Limited Manual Full Full Manual Limited
Integration with Artifact Repo None None Full Full None None
Roles and Policy Limited None Full Full None Full
On-Premise Support None None Full Full None None
Metrics None None None None Limited Full
Price min $150/mo By Storage Volume Free in Nexus OSS Included in Artifactory Pro min $12/mo By Storage Volume


Sometimes we overthink new things. Software delivery is very similar to manufacturing processes that have existed for a long time. You have a supply chain and a manufacturing process. In the supply chain you have approved vendors and the parts they provide. In the manufacturing process you have the collection of parts, the assembly, the quality assurance, and the delivery. If you consider your application as the product of a virtual version of this, then the artifacts in your application are just parts. And because Docker images are really just a new type of part their is no reason to treat them any different.

Organizations are already accustomed to dealing with components and artifacts. They have repositories that store the approved components. Just like a warehouse that stores all the parts for a car. When you build your application you go into your warehouse and collect all your approved parts. In the case of manufacturing, you are not going to use old versions of parts because they are old for a reason, likely they have been replaced for some reason even recalled due to issues they have. Same with software your repository will have not just the approved version, but the latest approved version. And you are not going to travel to the vendor of the part to get it, you will make sure that all parts are close to where they are assembled.

In this context it starts to seem obvious the benefits of an on-premise repository, the same repository you already use for your artifacts, as the place to store your Images. It is already integrated with your pipeline. It already has the roles and polices setup. It allows you to organize and share across your team.

A private registry does not mean it is on-premise. If your development is on-premise so is your registry. If your app dev is in the cloud, so is your registry. It is next to your application’s build process, and it is consistent with the processes and rules you have already built.

Docker does not need to be limited to DevTest. And to make it a sustainable solution does not require anything new. Finding the right private registry and configuring it to fit seamlessly into your pipeline does not come at a high effort cost, but provides tremendous value.

Watch this webinar one why and how to obtain a private registry

Chris Riley

Chris Riley (@hoardinginfo) is obsessed with bringing modern technologies to those who need to solve real-world problems, going from unicorn to reality. Chris speaks and engages with end users regularly in the areas of DevOps, SecOps and App Dev. He works for Splunk as a Tech Advocate and is a regular contributor to industry blogs such as, and He is also the host of the podcast, Developers Eating the World.

Chris Riley has 11 posts and counting. See all posts by Chris Riley