Harbor – The Enterprise-Grade Open Source Container Registry

Ok, we have a basic understanding of containers and a few of the architectural and operational challenges they come with. And of the DevOps practice that aims to improve software release and life-cycle management outcomes.

In the remaining posts of this series, I will present VMware’s and Pivotal’s approach to enabling enterprise container adoption as part of a larger DevOps initiative. (Pivotal Software spun out of VMware as a Paul Maritz initiative in 2012 . Originally, the ownership of Pivotal was VMware, EMC, and GE. The list of investors has grown, but VMware and Pivotal remain closely connected partners.).

VMware drives solutions through two channels. First, as any commercial software publisher does, with its ‘for sale’  commercial software. Second, within the open source community. VMware actively engages with the Open Source community through contributions to existing projects as well as developing, releasing, and leading new open source projects.

A partial list of container focused projects that VMware and Pivotal have donated to the open source community: Cloud Foundry, Bosh, Lightwave, Photon OS, Harbor, Xenon, Clarity, Admiral, Hatchway, Weathervane, vSphere Integrated Containers, and Kubo (k8s with Bosh by Pivotal and Alphabet).

On the commercial side, there are: Pivotal Cloud Foundry and VMware PKS (Kubo on vSphere).

This is a lot to cover. I will cover Harbor (An enterprise-grade registry that securely stores container images with built-in RBAC and image replication) in this post. I will likely dedicate at least one post, if not multiple, for each of the above.

A registry is where we store our containers so they can be instantiated on request. Without a registry, we have no convenient way of telling a host or orchestration tool to load a container and we have no way to centrally manage and maintain our ‘gold’ images.

There are two options when it comes to registries. A registry can be consumed as a service from a provider in the cloud. Or, it can be a service you provide on-premises. At a minimum (For compliance and security purposes), either form needs to provide access controls and auditing.

There are other features a registry can provide. For example, image scanning for known vulnerabilities, image replication between multiple registries, RESTful APIs, and encryption.. Typically, the open source versions offer minimal features and the commercial versions offer enterprise required features.

Harbor extends the open source Docker Registry to provide:

• Role Based Access Control – Users and docker repositories are organized via “projects”. Provides read only, read/write, and administrative controls for repositories.
• Image replication – Images can be replicated (synchronized) between multiple registry instances.
• Graphical user portal – Users can easily browse and search  repositories, and manage projects/namespaces.
• AD/LDAP support – Harbor integrates with existing enterprise AD/LDAP for authentication and user management.
• Auditing – All the operations to the repositories are logged for auditing purpose.
• I18n– Currently localized for English, Chinese, German, Japanese and Russian. More languages can be added.
• RESTful API – RESTful APIs are provided for most administrative operations of Harbor.
• Ease of deployment – Provides both an online and offline installer and a virtual appliance for vSphere platform (OVA).

Harbor is included with vSphere Integrated Containers (More on VIC later, it is supported with the vSphere Enterprise+ license, but is available as an open source project on GitHub) as a supported registry and available as a stand alone non-supported registry from GitHub.

I’m beginning with Harbor because a registry is fairly antonymous to an overall  container service architecture. It is a very robust registry service for being open source and may very well suit your needs.

I’ll cover vSphere Integrated Containers and the evolving approach VMware is taking with that approach in the next post.