These days, where many developers are working with containers and all their ‘outcomes’ are bundled in a Docker container, it is becoming challenging to manage and control them.

Moreover, as more containers and Kubernetes enter the party, the job gets that much harder. Now, you have a tool that can help you jump to the next level. The JFrog Container Registry is a new Docker, Helm, and generic registry that is scalable and reliable.

What’s even better?

It’s free… and gives you some unique features you can’t find anywhere else.

Give it a try at: jfrog.com/container-registry and/or continue to read below.

The Key Differentiators

When we are checking any new technology, it’s interesting to see what are the main features that we can utilize. Here is a shortlist of the main features you gain from the JFrog Container Registry.

Hybrid & Multi-Cloud

Yes! You can deploy the JFrog Container Registry in hybrid mode. In other words, you can install it on-perm and work with an instance in your private cloud (or any other public cloud vendor). From the beginning (over 10 years ago!), JFrog has been committed to enabling your freedom of choice and the solutions that work best for your needs.

Moreover, it is possible to host your infrastructure with one cloud vendor, while using services from a different cloud vendor. For example, having a registry on one provider and pulling images to a runtime environment on another provider. This might be useful when you wish to be on a multi-cloud for disaster recovery and reliability.

Docker & Helm Repository

It’s a full Docker registry that empowers you to manage all your containers. In addition, you can also use it as Helm registry, providing all you need to deploy to clusters through Kubernetes.

What is Helm?

Helm helps you manage Kubernetes applications. It’s a way to define, install, and upgrade even the most complex Kubernetes applications.

So it’s natural that you will want to have your Helm charts ‘near’ your containers. After all, you want it to work with your Kubernetes clusters, no?

Remote Repositories

A remote repository serves as a caching proxy for a repository managed at a remote URL (e.g. JCenter, npmjs or another Artifactory remote repository). Artifacts are stored and updated in remote repositories according to various configuration parameters that control the caching and proxying behavior.

Why is it important?

It’s essential because, with a remote repository, you only cache what you need on demand and not an entire registry. When you consider how Docker images can add up to many Gigabits, you can quickly understand how this is a critical aspect that save you time, money, and increases the productivity of your developers.

Virtual Repositories

A unique feature of JFrog Container Registry is the ability to aggregate several repositories into one collection to simplify access. After you configure it, your development team can refer to one URL for the deployment of artifacts. Moreover, for configuring build tools, there is a clear “one source of truth,” instead of managing and logging into multiple tools.

Generic repositories

An important capability that gives you the ability to work with the ‘unknown,’ this type of repository can be used to upload packages in any format. It’s beneficial when you want to:

1. Proxy unsupported package types
2. Share media files like: video, audio and images
3. Store installers
4. Navigation files
5. Any data that comes in a compressed binary format

What else?

There are many more features and great features like security scanning, REST APIs, the JFrog CLI and a great web app that lets you be productive. I’ll examine all these (and more) in the next post.

Give it a try at: jfrog.com/container-registry

And please let me know what was your experience at @greenido or in the comments below.

Thank you!