Harbor packaged by Bitnami¶

Harbor is an open source trusted cloud-native registry to store, sign, and scan content. It adds functionalities like security, identity, and management to the open source Docker distribution.

Overview of Harbor

TL;DR¶

使用加速地址添加仓库:

helm repo add bitnami "https://helm-charts.itboon.top/bitnami" --force-update
helm update bitnami

helm install my-release bitnami/harbor

Introduction¶

This Helm chart installs Harbor in a Kubernetes cluster. Welcome to contribute to Helm Chart for Harbor.

This Helm chart has been developed based on goharbor/harbor-helm chart but including some features common to the Bitnami chart library. For example, the following changes have been introduced:

• Possibility to pull all the required images from a private registry through the Global Docker image parameters.
• Redis® and PostgreSQL are managed as chart dependencies.
• Liveness and Readiness probes for all deployments are exposed to the values.yaml.
• Uses new Helm chart labels formatting.
• Uses Bitnami container images:
• non-root by default
• published for debian-10 and ol-7
• This chart support the Harbor optional components and Notary integrations.

Bitnami charts can be used with Kubeapps for deployment and management of Helm Charts in clusters.

Looking to use Harbor in production? Try VMware Application Catalog, the enterprise edition of Bitnami Application Catalog.

Prerequisites¶

• Kubernetes 1.19+
• Helm 3.2.0+
• PV provisioner support in the underlying infrastructure
• ReadWriteMany volumes for deployment scaling

Installing the Chart¶

To install the chart with the release name my-release:

helm install my-release bitnami/harbor

Uninstalling the Chart¶

To uninstall/delete the my-release deployment:

helm delete --purge my-release

Additionally, if persistence.resourcePolicy is set to keep, you should manually delete the PVCs.

Parameters¶

Global parameters¶

Common Parameters¶

Harbor common parameters¶

Traffic Exposure Parameters¶

Persistence Parameters¶

Tracing parameters¶

Volume Permissions parameters¶

NGINX Parameters¶

Harbor Portal Parameters¶

Harbor Core Parameters¶

Harbor Jobservice Parameters¶

Harbor Registry Parameters¶

Harbor Adapter Trivy Parameters¶

Harbor Exporter Parameters¶

PostgreSQL Parameters¶

Redis® parameters¶

Harbor metrics parameters¶

Specify each parameter using the --set key=value[,key=value] argument to helm install. For example,

helm install my-release \
  --set adminPassword=password \
    bitnami/harbor

The above command sets the Harbor administrator account password to password.

NOTE: Once this chart is deployed, it is not possible to change the application's access credentials, such as usernames or passwords, using Helm. To change these application credentials after deployment, delete any persistent volumes (PVs) used by the chart and re-deploy it, or use the application's built-in administrative tools if available.

Alternatively, a YAML file that specifies the values for the above parameters can be provided while installing the chart. For example,

helm install my-release -f values.yaml bitnami/harbor

Configuration and installation details¶

Rolling VS Immutable tags¶

It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.

Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.

Configure the way how to expose Harbor core¶

You can expose Harbor core using two methods:

• An Ingress Controller, exposureType should be set to ingress.
• An ingress controller must be installed in the Kubernetes cluster.
• If the TLS is disabled, the port must be included in the command when pulling/pushing images. Refer to issue #5291 for the detail.
• An NGINX Proxy, exposureType should be set to proxy. There are three ways to do so depending on the NGINX Proxy service type:
• ClusterIP: Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster:
• NodePort: Exposes the service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort service, from outside the cluster, by requesting NodeIP:NodePort.
• LoadBalancer: Exposes the service externally using a cloud provider's load balancer.

Configure the external URL¶

The external URL for Harbor core service is used to:

1. populate the docker/helm commands showed on portal
2. populate the token service URL returned to docker/notary client

Format: protocol://domain[:port]. Usually:

• if expose Harbor core service via Ingress, the domain should be the value of ingress.core.hostname.
• if expose Harbor core via NGINX proxy using a ClusterIP service type, the domain should be the value of service.clusterIP.
• if expose Harbor core via NGINX proxy using a NodePort service type, the domain should be the IP address of one Kubernetes node.
• if expose Harbor core via NGINX proxy using a LoadBalancer service type, set the domain as your own domain name and add a CNAME record to map the domain name to the one you got from the cloud provider.

If Harbor is deployed behind the proxy, set it as the URL of proxy.

Sidecars and Init Containers¶

If you have a need for additional containers to run within the same pod as any of the Harbor components (e.g. an additional metrics or logging exporter), you can do so via the sidecars config parameter inside each component subsection. Simply define your container according to the Kubernetes container spec.

core:
  sidecars:
    - name: your-image-name
      image: your-image
      imagePullPolicy: Always
      ports:
        - name: portname
        containerPort: 1234

Similarly, you can add extra init containers using the initContainers parameter.

core:
  initContainers:
    - name: your-image-name
      image: your-image
      imagePullPolicy: Always
      ports:
        - name: portname
          containerPort: 1234

Adding extra environment variables¶

In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the extraEnvVars property inside each component subsection.

core:
  extraEnvVars:
    - name: LOG_LEVEL
      value: error

Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the extraEnvVarsCM or the extraEnvVarsSecret values inside each component subsection.

Configure data persistence¶

• Disable: The data does not survive the termination of a pod.
• Persistent Volume Claim(default): A default StorageClass is needed in the Kubernetes cluster to dynamically provision the volumes. Specify another StorageClass in the storageClass or set existingClaim if you have already existing persistent volumes to use.
• External Storage(only for images and charts): For images and charts, the external storages are supported: azure, gcs, s3 swift and oss.

Configure the secrets¶

• Secrets: Secrets are used for encryption and to secure communication between components. Fill core.secret, jobservice.secret and registry.secret to configure then statically through the helm values. it expects the "key or password", not the secret name where secrets are stored.
• Certificates: Used for token encryption/decryption. Fill core.secretName to configure.

Secrets and certificates must be setup to avoid changes on every Helm upgrade (see: #107).

If you want to manage full Secret objects by your own, you can use existingSecret & existingEnvVarsSecret parameters. This could be useful for some secure GitOps workflows, of course, you will have to ensure to define all expected keys for those secrets.

The core service have two Secret objects, the default one for data & communication which is very important as it's contains the data encryption key of your harbor instance ! and a second one which contains standard passwords, database access password, ... Keep in mind that the HARBOR_ADMIN_PASSWORD is only used to boostrap your harbor instance, if you update it after the deployment, the password is updated in database, but the secret will remain the initial one.

Setting Pod's affinity¶

This chart allows you to set your custom affinity using the XXX.affinity parameter(s). Find more information about Pod's affinity in the kubernetes documentation.

As an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the bitnami/common chart. To do so, set the XXX.podAffinityPreset, XXX.podAntiAffinityPreset, or XXX.nodeAffinityPreset parameters.

Adjust permissions of persistent volume mountpoint¶

As the images run as non-root by default, it is necessary to adjust the ownership of the persistent volumes so that the containers can write data into it.

By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination.

You can enable this initContainer by setting volumePermissions.enabled to true.

Troubleshooting¶

Find more information about how to deal with common errors related to Bitnami's Helm charts in this troubleshooting guide.

Upgrading¶

To 16.0.0¶

This major updates the PostgreSQL subchart to its newest major, 12.0.0. Here you can find more information about the changes introduced in that version.

To any previous version¶

Refer to the chart documentation for more information about how to upgrade from previous releases.

License¶

Copyright © 2023 VMware, Inc.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.