Project reference ↗

Harbor gives a team a registry service for publishing and retrieving container images and other supported artifacts. It adds a place to manage access and artifact lifecycle within the organization's infrastructure, rather than relying only on a bare storage endpoint. It is useful when the platform needs a shared, controlled source of deployable images. Its availability depends on persistent artifact storage and supporting services as well as the registry containers themselves.

Chart ownership

The Harbor project publishes harbor-helm and distributes the harbor/harbor chart from helm.goharbor.io. Use a released chart and its matching values rather than copying the development branch. The chart exposes choices for network access, external URL and persistent or external artifact storage.

Before adoption

Availability depends on the registry's database, cache, storage and endpoint as well as replica counts. Review the selected release's dependency requirements rather than relying on old minimum versions in general architecture pages. Back up metadata and artifact content together, and test restoring an image that a deployment needs. Validate TLS trust, robot-account permissions, retention and garbage collection before allowing automated deletion. Keep a recovery path for cluster images if this registry becomes unavailable.

Sources & further reading

  1. Harbor Helm chart source
  2. Harbor availability architecture

Spotted something that needs another look?

Help improve this page →