Containers and Container Registries
Traditionally, Organizations have been deploying their software on “Bare metal” instances. Bare metal servers are often called single-tenant servers, meaning the server’s physical resources may not be shared between two or more tenants. This makes the operating system tightly coupled with the underlying hardware as we can have only one operating system on hardware. Like we can’t have Ubuntu and RHEL in single hardware, we can’t take advantage of both the OS for different projects, we have to choose one which best suits us and live with it.
Apart from being expensive, making small scale organizations hard to afford, developing an application was a nightmare for the developers as instead of focussing on the application, they have to take the bottom-up approach by looking at OS, they have to choose the libraries supported by that OS and then create the application.
Then virtualization came along, also known as bare-metal servers with Hypervisor, or more commonly called Virtual Machines.
It allowed multiple virtual machines to share single physical hardware, each machine having its own operating system, storage, and computation power, in an isolated fashion. It addressed the shortcomings faced with bare metal instances, also As VM’s could be cloned, migrated, spun up and down to meet demand faster as compared to traditionally bare metal instances it helps in responding more effectively to changes in business requirements, it also helped cut costs, as more VM’s could be spin up onto fewer physical machines.
But, again, they have their own share of problems, Provisioning a VM still takes a good amount of time as each VM containing a full operating system making is a memory and storage-intensive system. After a certain point, they are not able to deliver the kind of speed, agility, and savings that fast-moving businesses are demanding.
Now comes Docker containers, Containers utilized the concept of virtualization in a far more specific and granular way. It made it possible to have multiple containerized applications share a single, common operating system, but they are compartmentalized from one another and the system at large.
It isolates a single application and its dependencies on libraries that the app requires to run both from the underlying operating system and from other containers. It loosens the coupling between the application and underlying OS and eventually underlying hardware which means developers can develop their app in any of the distribution be it RHEL, Ubuntu, Fedora, and take advantage of different distributions in the different project without worrying about the underlying operating system.
As containerized apps use far less memory than virtual machines, they are fast to spin up and down which makes it easy to put new versions of software, with new business features, into production quickly and make scaling easy to meet demand. They also make it easier to implement strategies like blue/green deployments.
Docker Container Registries
A Docker image is a collection of files that bundle together all the essentials, such as installations, application code, and dependencies, required to configure a fully operational container environment. One can create a docker image for private use as well as make it public which can be used by anyone as it allows you to share container images with your team, customers, or the Docker community at large.
Now, To store these images, a physical disk is required, from where images can be pulled and pushed whenever required. Container registries also known as repositories are catalogs of storage locations. It is the physical location where your Docker images are actually stored.
Here comes Docker Hub, Docker’s official hosted repository service where one can access container images, shared by software vendors, open-source projects, and Docker’s community of users. You can also use this service to host and manage your own private images.
This is one solution that docker recommends as it’s managed by docker itself, we don't have to worry about downtime, security, management but it has its own share of problems like latency, as it is hosted on some third-party infrastructure, it takes time to pull the image to your own infrastructure. Second, If you are in the domain of finance like a Bank, or a fintech organization, there may be security and compliance issues to use third-party infrastructure to store images, which is nothing our code packed with dependencies. Lastly comes the Pricing part, Docker hub can be pretty expensive if you have a large team of developers as it charges $7 per month for each user.
To tackle the above-mentioned issues, we at KRISTAL.AI uses Self-hosted registries, where we have set up our registry on our own infrastructure.
While setting up a private repository, We brainstormed ourselves about the feature we look for in a private registry, and the list we came up with is
It should support SSL traffic, that is, should be able to serve HTTPS traffic. Second, should have an Authentication mechanism to log in to the UI, then it should have a simple and nice UI.
We have used JOXIT to have a nice UI for our repository. It’s an open-source GitHub project to provide a simple and complete user interface for private docker registries. It includes features to list all the repositories/images, list all tags for an image, display image size, and most importantly, by putting reverse proxy, NGINX in our case, on the front of the UI. It helps in serving HTTPS traffic. The reverse proxy takes care of HTTPS connections.
You can find more about JOXIT here https://github.com/Joxit/docker-registry-ui.
Now comes the Authentication part, to make it secure and allow only Authenticated users to access the repository, we at KRISTAL.AI used htpasswd authentication. In this method, credentials are store in a htpasswd file that contains rows corresponding to a pair of username and password separated with a colon character.
The password is encrypted using the UNIX system’s crypt method and may use MD5 or SHA1. Once set up, a user wishing to access a restricted site will be requested a username and password pair to gain access. Only correct pairs will grant access to the requested site.
From the instance where you want to pull and push images from, you can do docker login with your private repo path, and once authenticated you would be able to push and pull images.
[centos@jenkins-dev ~]$ docker login https://privaterepo.kristal.ai
Username: testcred
Password:
Login SucceededThanks
