Why you need your own Docker Hub?

Do not depend on images — you indispensable rely on!

In an infrastructure based on containers you surprise wise start depending on images. Which can become a real problem if they are not available.

Wherever you look there is this flagship “high availability” with which everyone advertises. With this self burdening promise comes also a responsibility. This is exactly where concepts like Kubernetes and CI/CD comes into play. These concepts allow us to serve better uptimes for our applications. Make our releases more error insusceptible.

All these solutions have something in common: Images

If you don’t build them from scratch, a typical snippet could look like this in your Dockerfile:

FROM ubuntu:20.04

That is where the problem arises!

To address this issue we have many options in hand. The first obvious choice would be building base images on our own. But for real

“Ain’t nobody got time for that”

Be aware of your “own” images

In the beginning you will start making images by building on top of common base images. Which is fine you could start thinking. You pick a base image like “ubuntu 20.04” and put code on top. Then we gonna push it into Docker Hub.

I made the same assumption and then there is this little phrase:

Anything that can go wrong will go wrong

Imagine we have to provide a new release of our software ASAP. We are working on a demonstration, which makes us without there already uncomfortable. You type in “docker pull ubuntu:20.04”….

Yes! Somehow it isn’t reachable. No base image = No final image!

That is a simple example and I admit it is quite dramatic. But I guess you get the point. Don’t rely on something so simple as pulling base images.

Building your own registry isn’t that hard

Don’t be afraid — I wont repeat what is better described in many other articles. There is nothing new in the concept of having a private registry. But somehow I still wonder again and again that companies still don’t have any.

And yet it is so simple:

docker run -d -p 5000:5000 registry:2

You are free!

I know, building a high available registry is more than that. But it would be a beginning.

And then there were services

Okay we solved the problem on our local machine and also when it comes to our own applications. But what is with services we might run like: Databases, Monitoring, Logging, Loadbalancer….

If you run Kubernetes for example, those are also provided in images. These services are in most cases as important as your own applications.

As container infrastructures are agile and dynamic, it is also dependent on images. With pulling those again and again, it gets one of the essential mechanics. Yes — there is local image storage for making this process easier to address. Local images can differ to the one we want to address, even if the tags are the same. So that constant check on changes is a dependency we created.

In a professional setup there is now way in getting around storing common images.

Wait — no way we gonna push all these images in our private registry by hand!

That is not what I would suggest. Also otherwise I would not build my own script that does that for me.

The answer is a mirror registry or also called proxy cache. This handy tool can cache every image I pulled once into our registry. So when your cluster pulls “mysql:8.0” for example, it will ask your proxy cache. This type of registry will pull it once from Docker Hub and store it afterwards. Next time your cluster asks for the same image, it will already be there.

That is how you will free yourself from relying on images.

Speed, speed and again speed

Having images lay inside the enterprise network can lead to better puling speed. Therefore it saves time and costs. Services or CI/CD pipelines should run in an unrestricted tempo. With a private registry or even a proxy cache you can reduce those significant.

Summary

Don’t rely on images that you haven’t stored in a private registry. More and more services getting advertised as “high available” to the public. When you look under the hood they run containers on common base images or with common services. That’s where the trouble can begin, if they aren’t available somehow.

Thanks for reading and have a happy building.

System Engineer @Fraunhofer on that behalf I’m interested in state of the art tech. Otherwise I’m totally into martial arts and fitness.