Containerization did to Cloud Computing, what sliced bread did to breakfast options.
A few similarities:
Scalability – friends or neighbours show up unexpectedly, you open a fresh packet. Container orchestration systems like Kubernetes, can scale an app to meet a surge in demand, such as a retail app that needs to service more customers on a busy holiday shopping day.
Portability – feel like breakfast in the park, sliced bread comes along conveniently. Containers are very portable too – helping move code between environments, such as from on premise systems to a cloud, or moving a microservice through the build, test, and production cycle.
Security – is there the slightest hint of a lack of freshness, throw the pack away and get a fresh one. When there are issues with code in a specific container (like a memory leak), we can identify and isolate the code issues and fix this by replacing the unhealthy container with a healthy one, without needing to take the entire application down.
All of this is made possible with the help of container images – the bunch of static files, which run within containers to create multiple instances of the application. And it is this image which can be shipped to another location to spin up the app there.
This brings us to the storage repository for the images – which serves as an intermediary for sharing images between systems. This collection of repositories as well as indexes, access control rules, and API paths is the Container Registry.
Developers are not restricted to use the cloud container registry from their specific cloud vendor — even if they use that vendor’s container service. Choosing the right image registry that meets all your production requirements is critical to the success of any application development cycle. Any issues with your registry, and the entire development cycle gets disrupted!
Fig.1 – Container registry as an intermediary
Options for Container Registries
Docker Hub – Docker Hub is popular among developers for its ease of use; familiar collaboration model, similar to GitHub) and integration options. it’s also the de facto option for open source containers. It offers its registry for free and comes built into Docker tools.
When you run the docker push and docker pull commands on your server, this is the default registry used.
If you want to use Docker Hub as a repository privately opt for the premium plan. As part of the premium feature, you also benefit from security scanning to identify any vulnerabilities in your images.
Cons:
- Lacks fine-grained access control.
- Does not provide any insight into the registry usage.
- Lacks LDAP, SAML and OAuth support.
- Registry performance can be inconsistent (reported issue with deleting images).
Limited features and lack of comprehensive access management features, make enterprise users to shy away from using this option.
Quay is the container registry from Red Hat, symbolically named after the platform on a river bank for boats to unload. Popular for its enterprise-level security features and easy to use UI, it has wide acceptance. Supporting most functions of container image management, including automated geographic replication, Quay offers robust access control – LDAP and OAuth integrations; and logging.
Image Time Machine or rollback is a unique feature which helps to view history of images and easily switch image builds. Transport Layer Security encryption helps you transit between Quay.io (the hosted SaaS version) and your servers automatically. Quay supports automated security scanning of container images to find known vulnerabilities on the fly.
Cons: While Quay; meets most enterprise expectations for a Container registry, few users feel, It could be better integrated with other platforms – e.g.) older versions of Red Hat does not naturally integrate into the registry and needs configuration.
AWS EC2 Container Registry (ECR)
Amazon ECR is integrated with Amazon ECS allowing you to easily store, run, and manage container images for applications running on Amazon ECS. All you need to do is specify the Amazon ECR repository in your Task Definition and Amazon ECS will retrieve the appropriate images for your applications.
Being integrated with the AWS ecosystem means you can pull and push container images from the ECR without worrying about server latency. Security is also easier to manage since you can use the IAM service control panel to govern access to your ECR instance. While AWS offers the capability to specify policies at the repository level, ECR supports vulnerability scanning. Tight integration with Amazon ECS and the Docker CLI, allows you to simplify your development and production workflows.
Costs are reasonable with no upfront fees or commitments. You pay only for data you store in your repositories and data transferred to the Internet.
Cons:
- Use with docker client requires creating a temporary token.
- Potentially expensive if the containers being deployed are not in AWS.
- Users can transfer data out of ECR and into an Elastic Compute Cloud instance in the same region without cost. However, data transfers to different regions will add additional costs.
AWS doesn’t offer a straightforward way to spread container images across multiple regions, and ECR is designed as a regional service. To achieve geo-redundancy in ECR, users must manually set up multiple registries in different regions — and keeping those images in sync would require significant effort.
It supports all kinds of containers, including Mesosphere. Azure manages network latency by leveraging its vast cloud computing network and making sure that the closest clusters are used. If you use Azure Kubernetes Service (AKS) this is definitely the registry to utilize. The interactions between the two Microsoft services are incredibly fluid. Azure Container Registry lets users configure geo-replication, in the premium service tier.
Cons: Azure Container Registry has a more complicated pricing structure. Microsoft breaks the costs into three tiers, each of which is billed at a fixed price per day with a fixed amount of storage. That structure might seem simple, but it doesn’t include network bandwidth charges, which are billed separately. Users also must pay separately for container image builds, per second of CPU time. That cost is minimal for many users, but it could add up for those who rebuild container images frequently.
Google, the company behind Kubernetes, isn’t left behind in offering a capable registry with native Docker support and automatic build and deploy. The Google Container Registry or GCR is one of the most affordable options on the market; you only pay for the storage and bandwidth you use.
It also comes with all the features you would need to set up a repository for your projects. Security is enterprise-grade with vulnerability scanning and fine-grained access control. By default, Google Container Registry stores data in a multi-regional storage bucket.
Geo-redundancy enables container images to be spread across multiple clouds; if one region becomes unavailable, users can access the container images from another region. Geo-redundancy can also improve performance because it enables enterprises to place container images in data centers that are geographically close to users.
Cons: Google Container Registry requires developers to use Google’s software development kit command-line tool to push and pull container images.
Talk with us today to figure out the right option for your particular use case.
