With the GA release of vSphere Integrated Containers (aka VIC) on December, VMware also announced an enterprise class registry server based on the open source Docker Distribution that allows us to store and distribute container images in our datacenter. While VIC Engine (actually the core component of VIC) is great for providing a container runtime for vSphere, enterprise customers governed by strict regulations require a more private solution in order to store and manage container images rather than the default cloud-based registry service from Docker. Docker has already a private solution, which is called Trusted Registry, but the lack of enterprise grade functionalities such as increased control and security, identity and management triggered this open source project, Project Harbor.
Project Harbor extends Docker Trusted Registry and adds the following features,
- Role based access control: Users and repositories are well organized and a user can have different permissions for images under a project.
- Policy based image replication: Images can be replicated (synchronized) between multiple registry instances.
- LDAP/AD support: Harbor integrates with existing enterprise LDAP/AD for user authentication and management.
- Image deletion & garbage collection: Images can be deleted and their space can be recycled.
- Graphical user portal: Users can easily browse, search repositories and manage projects.
- Auditing: All the operations to the repositories are tracked.
- RESTful API: RESTful APIs for most administrative operations, easy to integrate with external systems.
- Easy deployment: Provide both an online and offline installer. Besides, a virtual appliance for vSphere platform (OVA) is available.
It’s possible to download the binary from My VMware Portal which is required to install Harbor as a virtual appliance. If we are not eligible to reach the binary through the portal, we can always visit the GitHub page of the project for manual installation and the OVA file.
Let’s assume that we have decided to use the OVA format in the name of the ease of the deployment. As there are many options we need to provide, such as regular virtual appliance options (hostname, datastore, IP configuration) and application specific configurations (passwords, SMTP configuration and a few harbor specific options), the most important one is the one that configures the authentication method that Harbor will be configured with. It can be either LDAP authentication or database authentication but it cannot be modified after the installation, if required, we have to install a fresh instance. LDAP authentication is a good practice because it will save us from managing custom users within the database and will be more secure. Below are the options that we need to provide (please modify according to your domain)
- Authentication mode: ldap_auth
- LDAP URL: ldap://DomainController.demo.local
- LDAP Search DN: CN=User2MakeQueries,OU=Users,DC=demo,DC=local
- LDAP Search Password: Password of the above user
- LDAP Base DN: OU=OrganizationUnitInWhichUsersWillBeQueried,DC=demo,DC=local
- LDAP UID: The filter to query the users, such as uid, cn, email, sAMAccountName or any other attribute.
After the installation, it’s highly recommended to change the admin password of Harbor provided by us during the deployment phase because it will persist in the configuration file (/harbor/harbor/harbor.cfg) in plain text.
It will take a few minutes to complete the installation. If we set the “Permit Root Login” option to ‘true’ during the deployment phase, we can connect to the server via SSH with root credentials and begin to play around. The deployed operating system is Photon OS and the sub-components of Harbor are actually running as containers. When we run docker ps -a, all those running containers come to daylight. Harbor consists of six containers composed by docker-compose.
- Proxy: This is a NGINX reverse-proxy. The proxy forwards requests from browsers and Docker clients to backend services such as the registry service and core services.
- Registry: This registry service is based on Docker Registry 2.5 and is responsible for storing Docker images and processing Docker push/pull commands.
- Core Services: Harbor’s core functions, which mainly provides the following services:
- UI: A graphical user interface to help users manage images on the Registry
- Webhook: Webhook is a mechanism configured in the Registry so that image status changes in the Registry can be populated to the Webhook endpoint of Harbor. Harbor uses webhook to update logs, initiate replications, and some other functions.
- Token service: Responsible for issuing a token for every docker push/pull command according to a user’s role of a project. If there is no token in a request sent from a Docker client, the Registry will redirect the request to the token service.
- Database: Derived from official MySQL image and is responsible for storing the metadata of projects, users, roles, replication policies and images.
- Job Services: This service is responsible for image replication to other Harbor instances (if there are any).
- Log Collector: This service is responsible for collecting logs of other modules in a single place.
And this is what it looks like from an architectural point of view;
All the blue boxes shown in the diagram are running as containers. If we would like to know more about those containers and how they are configured, we can always run docker inspect commands on them.
docker inspect nginx docker inspect harbor-jobservice docker inspect harbor-db docker inspect registry docker inspect harbor-ui docker inspect harbor-log
As a result of the inspect commands, the thing that attracts my attention is the persistent volume configurations. By their nature, containers are immutable and disposable. So in order to keep the data and the service configurations persistent, Harbor takes advantage of volume mounts between the docker host and the containers. And it’s also useful to modify configuration of the services and to replace the ui certificate.
This is the list of the volume mounts (sources and destinations) used in all containers.
We can now enjoy and push images to our on-prem brand new registry server.