harbor Documentation

1. Project Overview & Quickstart (goharbor/harbor) Copy Chapter

File: README.md Copy Chapter

Harbor

Note: The main branch may be in an unstable or even broken state during development.
Please use releases instead of the main branch in order to get a stable set of binaries.

Harbor is an open source trusted cloud native registry project that stores, signs, and scans content. Harbor extends the open source Docker Distribution by adding the functionalities usually required by users such as security, identity and management. Having a registry closer to the build and run environment can improve the image transfer efficiency. Harbor supports replication of images between registries, and also offers advanced security features such as user management, access control and activity auditing.

Harbor is hosted by the Cloud Native Computing Foundation (CNCF). If you are an organization that wants to help shape the evolution of cloud native technologies, consider joining the CNCF. For details about who is involved and how Harbor plays a role, read the CNCF
announcement.

Features Copy Chapter

• Cloud native registry: With support for both container images and Helm charts, Harbor serves as registry for cloud native environments like container runtimes and orchestration platforms.
• Role based access control: Users access different repositories through 'projects' and a user can have different permission for images or Helm charts under a project.
• Policy based replication: Images and charts can be replicated (synchronized) between multiple registry instances based on policies with using filters (repository, tag and label). Harbor automatically retries a replication if it encounters any errors. This can be used to assist loadbalancing, achieve high availability, and facilitate multi-datacenter deployments in hybrid and multi-cloud scenarios.
• Vulnerability Scanning: Harbor scans images regularly for vulnerabilities and has policy checks to prevent vulnerable images from being deployed.
• LDAP/AD support: Harbor integrates with existing enterprise LDAP/AD for user authentication and management, and supports importing LDAP groups into Harbor that can then be given permissions to specific projects.
• OIDC support: Harbor leverages OpenID Connect (OIDC) to verify the identity of users authenticated by an external authorization server or identity provider. Single sign-on can be enabled to log into the Harbor portal.
• Image deletion & garbage collection: System administrators can run garbage collection jobs so that images (dangling manifests and unreferenced blobs) can be deleted and their space can be freed up periodically.
• Graphical user portal: User can easily browse, search repositories and manage projects.
• Auditing: All the operations to the repositories are tracked through logs.
• RESTful API: RESTful APIs are provided to facilitate administrative operations, and are easy to use for integration with external systems. An embedded Swagger UI is available for exploring and testing the API.
• Easy deployment: Harbor can be deployed via Docker compose as well Helm Chart, and a Harbor Operator was added recently as well.

Architecture Copy Chapter

For learning the architecture design of Harbor, check the document Architecture Overview of Harbor.

API Copy Chapter

• Harbor RESTful API: The APIs for most administrative operations of Harbor and can be used to perform integrations with Harbor programmatically.
  • Part 1: New or changed APIs

Install & Run Copy Chapter

System requirements:

On a Linux host: docker 20.10.10-ce+ and docker-compose 1.18.0+.

Download binaries of Harbor release and follow Installation & Configuration Guide to install Harbor.

If you want to deploy Harbor on Kubernetes, please use the Harbor chart.

Refer to the documentation for more details on how to use Harbor.

Verifying Release Signatures Copy Section

Starting with v2.15.0, Harbor release artifacts are cryptographically signed using Cosign to ensure authenticity and integrity.

Download the installers and signature bundles from the Harbor releases page.

Quick Verification

# Install Cosign (v2.0+)
brew install sigstore/tap/cosign

# Verify signature
cosign verify-blob \
  --bundle harbor-offline-installer-v2.15.0.tgz.sigstore.json \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/goharbor/harbor/.github/workflows/publish_release.yml@refs/tags/v.*$' \
  harbor-offline-installer-v2.15.0.tgz

• Expected output: Verified OK

• Full verification guide: docs/signature-verification.md

OCI Distribution Conformance Tests Copy Chapter

Check the OCI distribution conformance tests report of Harbor.

Compatibility Copy Chapter

The compatibility list document provides compatibility information for the Harbor components.

• Replication adapters
• OIDC adapters
• Scanner adapters

Community Copy Chapter

• Twitter: @project_harbor
• User Group: Join Harbor user email group: [email protected] to get update of Harbor's news, features, releases, or to provide suggestion and feedback.
• Developer Group: Join Harbor developer group: [email protected] for discussion on Harbor development and contribution.
• Slack: Join Harbor's community for discussion and ask questions: Cloud Native Computing Foundation, channel: #harbor and #harbor-dev

Demos Copy Chapter

• Live Demo - A demo environment with the latest Harbor stable build installed. For additional information please refer to this page.
• Video Demos - Demos for Harbor features and continuously updated.

Partners and Users Copy Chapter

For a list of users, please refer to ADOPTERS.md.

Security Copy Chapter

Security Audit Copy Section

A third party security audit was performed by Cure53 in October 2019. You can see the full report here.

Reporting security vulnerabilities Copy Section

If you've found a security related issue, a vulnerability, or a potential vulnerability in Harbor, do not file a public issue. Report it privately via GitHub private vulnerability reporting: open the
Security tab and click Report a vulnerability. The Harbor Security Team will acknowledge your report, and will follow up in the advisory
thread once we've identified the issue positively or negatively.

For further details please see our complete security release process.

License Copy Chapter

Harbor is available under the Apache 2 license.

This project uses open source components which have additional licensing terms. The official docker images and licensing terms for these open source components can be found at the following locations:

• Photon OS 1.0: docker image, license

Fossa Status Copy Chapter

File: api/v2.0/README.md Copy Chapter

References

This file lists all the files that are referring the swagger yaml file.

• Makefile
  • java -jar swagger-codegen-cli.jar generate -i api/harbor/swagger.yaml -l python -o harborclient
• README
  • Harbor RESTful API in API section
• docs/configure_swagger.md
  • https://raw.githubusercontent.com/goharbor/harbor/master/api/harbor/swagger.yaml
• make/photon/portal/Dockerfile
  • COPY ./api/v2.0/swagger.yaml /build_dir/swagger.yaml
• tests/swaggerchecker.sh
  • HARBOR_SWAGGER_FILE="https://raw.githubusercontent.com/$TRAVIS_REPO_SLUG/$TRAVIS_COMMIT/api/harbor/swagger.yaml"
  • else HARBOR_SWAGGER_FILE="https://raw.githubusercontent.com/$TRAVIS_PULL_REQUEST_SLUG/$TRAVIS_PULL_REQUEST_SHA/api/harbor/swagger.yaml"

Notes: Base path is the code repository root dir.

File: contrib/grafana-dashboard/README.md Copy Chapter

Grafana Dashboard

This dashboard can be used to visualize metrics from the Harbor Exporter.

The dashboard was created with Grafana v8 and may not work with older versions of Grafana.

Screenshot Copy Chapter

File: contrib/README.md Copy Chapter

The contrib directory contains documents, scripts, and other helpful things which are contributed by the community.

File: docs/img/README.md Copy Chapter

Note: The harbor_logo.png is referenced by the Harbor helm charts which are already released, don't remove it

File: docs/README.md Copy Chapter

Harbor Documentation

All Harbor documentation is presented on goharbor.io/docs.

To contribute to the documentation, please head over to the website repository.

File: src/jobservice/README.md Copy Chapter

Job Service

Job service is designed to handle and process the asynchronous background jobs with an easy way. It is built on top of gocraft/work job queue framework with supporting

• Fast and efficient.
• Reliable - don't lose jobs even if your process crashes.
• If a job fails, it will be retried a specified number of times.
• Schedule jobs to happen in the future.
• Enqueue unique jobs so that only one job with a given name/arguments exists in the queue at once.
• Periodically enqueue jobs on a cron-like schedule.

and the following additional capabilities:

• Rest API.
• Execution context.
• More job status: error,success,stopped,cancelled and scheduled.
• More controllable actions: stop and cancel.
• Enhanced periodical jobs.
• Status web hook.

Use cases Copy Chapter

With job service, you can:

• Submit a Generic job which will be executed immediately if worker resource is available and can be only execute once.
• Submit a Scheduled job which will be executed after a specified delay.
• Submit a Periodic job which will be repeatedly executed with specified interval.
• Submit job with unique flag to make sure no duplicated jobs are executing at the same time.
• Stop a specified job.
• Cancel a specified job.
• Retry a specified job (This should be a failed job and match the retrying criteria).
• Get stats of specified job (no list jobs function).
• Get execution log of specified job (It depends on the logger implementation).
• Check the health status of job service.(No authentication required, it can be used as health check endpoint)

Architecture Copy Chapter

The overall architecture of the job service is shown in the below graph:

Components:

• API Server: A go lightweight restful API server to serve the related restful requests.
• Configuration Manager: Responsible for handing the configurations used in job services. Two sources supported: yaml file and env variables.
• Bootstrap: Take the responsibilities to initialize related context and start API server and worker pool. The main start point of job service.
• Controller: The core of job service. Responsible for coordinating the whole flow of job service.
• Job Launcher : Launch the jobs except Periodic ones.
• Scheduler: Schedules the Periodic jobs.
• Logger: A flexible logger framework. It will catch and write the job execution logs to the configured backends.
• Stats Manager: Maintains the status and stats of jobs as well as status hooks.
• Data Backend: Define storage methods to store the additional info.
• Pool Driver: A interface layer to broke the functions of upstream job queue framework to upper layers.
• Persistent driver: So far, only support redis.

Currently, the worker (compute node) and controller (control plane) are packaged in one process. To achieve scalability and HA functionality, multiple nodes can be deployed under a LB layer.

As described in above graph, the controller and work pool which are located in different nodes can also talk to each other via a virtual channel - the backend persistent driver. That means the job enqueued by a controller may be selected by other worker pool which is located in another node.

Programming Model Copy Chapter

To let the job service recognize the job, the implementation of job should follow the programming model.

Job Interface Copy Section

A valid job must implement the job interface. For the details of each method defined in the job interface, you can refer the comments attached with the method.

// Interface defines the related injection and run entry methods.
type Interface interface {
	// Declare how many times the job can be retried if failed.
	//
	// Return:
	// uint: the failure count allowed. If it is set to 0, then default value 4 is used.
	MaxFails() uint

	// Max currency of the job. Unlike the WorkerPool concurrency, it controls the limit on the number jobs of that type
	// that can be active at one time by within a single redis instance.
	//
	// The default value is 0, which means "no limit on job concurrency".
	MaxCurrency() uint

	// Tell the worker worker if retry the failed job when the fails is
	// still less that the number declared by the method 'MaxFails'.
	//
	// Returns:
	//  true for retry and false for none-retry
	ShouldRetry() bool

	// Indicate whether the parameters of job are valid.
	//
	// Return:
	// error if parameters are not valid. NOTES: If no parameters needed, directly return nil.
	Validate(params Parameters) error

	// Run the business logic here.
	// The related arguments will be injected by the workerpool.
	//
	// ctx Context                   : Job execution context.
	// params map[string]any : parameters with key-pair style for the job execution.
	//
	// Returns:
	//  error if failed to run. NOTES: If job is stopped or cancelled, a specified error should be returned
	//
	Run(ctx Context, params Parameters) error
}

Just pay attention, your main logic should be written in the Run method.

Job Context Copy Section

A job context will be provided when executed the Run logic. With this context, you can

• Get a logger handle if you want to output the execution log to the log backends.
• Retrieve the system context reference.
• Get job operation signal if your job supports stop and cancel.
• Get the checkin func to check in message.
• Get properties by key
• Specified to harbor, db connection and all the configurations can be retrieved by context.

Cancellable Job Copy Section

To make the job cancellable, some special logic should be coded in the Run logic.

First, check the signal at certain execution points,

if cmd, ok := ctx.OPCommand(); ok {}

Then, check if it is a cancel signal,

if cmd == opm.CtlCommandCancel {}

finally, if it is, exit the logic and return the cancel error.

return errs.JobCancelledError()

Stoppable Job Copy Section

To make the job stoppable, some special logic should be coded in the Run logic.

First, check the signal at certain execution points,

if cmd, ok := ctx.OPCommand(); ok {}

Then, check if it is a stop signal,

if cmd == opm.CtlCommandStop {}

finally, if it is, exit the logic and return the cancel error.

return errs.JobStoppedError()

Check In Message Copy Section

If you want to report more concrete status info, just call the Checkin function in the job context like the below code piece shown:

ctx.Checkin("30%")

Job Implementation Sample Copy Section

Here is a demo job:

/* Detailed source-code truncated for AI context efficiency. */

Job Execution Copy Chapter

Job execution is used to track the jobs which are related to a specified job, like parent and children jobs. If one job has executions, the following two extra properties will be appended to the job stats.

{
      "job": {
          "executions": ["uuid-sub-job"],
          "multiple_executions": true
      }
}

For the job execution/sub job, there will be an extra property upstream_job_id pointing to id of the upstream (/parent) job.

{
      "job": {
          "upstream_job_id": "parent-id"
      }
}

Under that situation, the flag multiple_executions will be set to be true. The list executions will contain all the ids of the executions (/sub jobs).

General job Copy Section

Any jobs can launch new jobs through the launch function in the job context. All those jobs will be tracked as sub jobs (executions) of the caller job.

func (j *Job) Run(ctx job.Context, params job.Parameters) error{
    // ...
    subJob, err := ctx.LaunchJob(models.JobRequest{})
    // ...

    return nil
}

Periodic job Copy Section

The job launched with Periodic kind is actually a scheduled job template which will be not run directly. The real running job will be created by cloning the configurations from the job template and run. And then each periodic job will have multiple job executions with independent id and each job execution will link to the Periodic job by the upstream_job_id.

Logger Copy Section

There are two loggers here. One is for job service itself and another one is for the running jobs. Each logger can configure multi logger backends.

Each backend logger is identified by an unique name which will be used in the logger configurations to enable the corresponding loggers. Meanwhile, each backend logger MUST implement the logger.Interface. A logger can also support (optional):

• sweeper: Sweep the outdated logs. A sweeper MUST implement sweeper.Interface
• getter: Get the specified log data. A getter MUST implement getter.Interface

All the backend loggers SHOULD onboard via the static logger registry.

// knownLoggers is a static logger registry.
// All the implemented loggers (w/ sweeper) should be registered
// with an unique name in this registry. Then they can be used to
// log info.
var knownLoggers = map[string]*Declaration{
	// File logger
	LoggerNameFile: {FileFactory, FileSweeperFactory, FileGetterFactory, false},
	// STD output(both stdout and stderr) logger
	LoggerNameStdOutput: {StdFactory, nil, nil, true},
}

So far, only the following two backends are supported:

• STD_OUTPUT: Output the log to the std stream (stdout/stderr)
• DB: Output the log to the database with the table name job_log
• FILE: Output the log to the log files
  • sweeper supports
  • getter supports

Configure loggers Copy Section

Logger configuration options:

An example:

#Loggers
loggers:
  - name: "STD_OUTPUT" # logger backend name, only support "DB", "FILE" and "STD_OUTPUT"
    level: "DEBUG" # INFO/DEBUG/WARNING/ERROR/FATAL
  - name: "FILE"
    level: "DEBUG"
    settings: # Customized settings of logger
      base_dir: "/tmp/job_logs"
    sweeper:
      duration: 1 #days
      settings: # Customized settings of sweeper
        work_dir: "/tmp/job_logs"
  - name: "DB"
    level: "DEBUG"
    sweeper:
      duration: 1 #days

Configuration Copy Chapter

The following configuration options are supported:

Sample Copy Section

---
#Protocol used to serve
protocol: "https"

#Config certification if use 'https' protocol
https_config:
  cert: "server.crt"
  key: "server.key"

#Server listening port
port: 9443

#Worker pool
worker_pool:
  #Worker concurrency
  workers: 10
  backend: "redis"
  #Additional config if use 'redis' backend
  redis_pool:
    #redis://[arbitrary_username:password@]ipaddress:port/database_index
    #or ipaddress:port[,weight,password,database_index]
    redis_url: "localhost:6379"
    namespace: "harbor_job_service"

#Loggers for the running job
job_loggers:
  - name: "STD_OUTPUT" # logger backend name, only support "DB", "FILE" and "STD_OUTPUT"
    level: "DEBUG" # INFO/DEBUG/WARNING/ERROR/FATAL
  - name: "FILE"
    level: "DEBUG"
    settings: # Customized settings of logger
      base_dir: "/tmp/job_logs"
    sweeper:
      duration: 1 #days
      settings: # Customized settings of sweeper
        work_dir: "/tmp/job_logs"
  - name: "DB"
    level: "DEBUG"
    sweeper:
      duration: 1 #days

#Loggers for the job service
loggers:
  - name: "STD_OUTPUT" # Same with above
    level: "DEBUG"

API Copy Chapter

Authorization Copy Section

As job service is always running in the backend environment, a simple secret auth way is choose now. To call the job service API, the Authorization header must be appended.

Authorization : Harbor-Secret <secret>

The expected secret is passed to job service by the ENV variable CORE_SECRET.

Endpoints Copy Section

POST /api/v1/jobs

Submit jobs

• Request body

{
    "job": {
        "name": "demo",
        "parameters": {
            "p1": "just a demo"
        },
        "status_hook": "https://my-hook.com",
        "metadata": {
            "kind": "Generic", // or "Scheduled" or "Periodic"
            "schedule_delay": 90, // seconds, only required when kind is "Scheduled"
            "cron_spec": "* 5 * * * *", // only required when kind is "Periodic"
            "unique": false
        }
    }
}

• Response

  • 202 Accepted
  json Copy

  {
      "job": {
          "id": "uuid-job",
          "status": "pending",
          "name": "DEMO",
          "kind": "Generic",
          "unique": false,
          "ref_link": "/api/v1/jobs/uuid-job",
          "enqueue_time": "2018-10-10 12:00:00",
          "update_time": "2018-10-10 13:00:00",
          "multiple_executions": false // To indicate if the job has sub executions
      }
  }

  • 401/500 Error
  json Copy

  {
      "code": 500,
      "err": "short error message",
      "description": "detailed error message"
  }

GET /api/v1/jobs/{job_id}

Get job stats

• Response

  • 200 OK
  json Copy

  {
      "job": {
          "id": "uuid-job",
          "status": "pending",
          "name": "DEMO",
          "kind": "Periodic",
          "unique": false,
          "ref_link": "/api/v1/jobs/uuid-job",
          "enqueue_time": 1539164886,
          "update_time": 1539164886,
          "run_at": 1539164986,
          "cron_spec": "* 5 * * * * ",
          "check_in": "check in message", // if check in message
          "check_in_at": 1539164889, // if check in message
          "die_at": 0,
          "hook_status": "http://status-check.com",
          "executions": ["uuid-sub-job"], // the ids of sub executions of the job
          "multiple_executions": true
      }
  }

  • 401/500 Error
  json Copy

  {
      "code": 500,
      "err": "short error message",
      "description": "detailed error message"
  }

POST /api/v1/jobs/{job_id}

Stop/Cancel/Retry job

• Request body

{
    "action": "stop" //or "cancel" or "retry"
}

• Response

  • 204 No content
  • 401/404/500/501 Error
  json Copy

  {
      "code": 500,
      "err": "short error message",
      "description": "detailed error message"
  }

GET /api/v1/jobs/{job_id}/log

Retrieve job log

• Response

  • 200 OK

  Log text bytes

  • 401/400/404/500 Error
  json Copy

  {
      "code": 500,
      "err": "short error message",
      "description": "detailed error message"
  }

GET /api/v1/stats

Check job service healthy status

• Response

  • 200 OK
  json Copy

  [{
      "worker_pool_id": "pool1",
      "started_at": 1539164886,
      "heartbeat_at": 1539164986,
      "job_names": ["DEMO"],
      "concurrency": 10,
      "status": "healthy"
  }]

  • 401/500 Error
  json Copy

  {
      "code": 500,
      "err": "short error message",
      "description": "detailed error message"
  }

How to Run Copy Chapter

It's easy to run the job service.

• First, compile and build the binary

// under jobservice folder
go build -a -o jobservice

• Second, create configuration yaml file and configure the job service.

• Then, export the secret via ENV variable CORE_SECRET.

• Finally, start the service with the following command,

jobservice -c <config_yaml_file_path>

Enjoy it!

File: src/pkg/chart/testdata/harbor-schema2/README.md Copy Chapter

Helm Chart for Harbor

Notes: The master branch is in heavy development, please use the other stable versions instead. A highly available solution for Harbor based on chart can be found here. And refer to the guide to upgrade the existing deployment.

This repository, including the issues, focuses on deploying Harbor chart via helm. For functionality issues or Harbor questions, please open issues on goharbor/harbor

Introduction Copy Chapter

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

Prerequisites Copy Chapter

• Kubernetes cluster 1.20+
• Helm v3.2.0+

Installation Copy Chapter

Add Helm repository Copy Section

helm repo add harbor https://helm.goharbor.io

Configure the chart Copy Section

The following items can be set via --set flag during installation or configured by editing the values.yaml directly (need to download the chart first).

Configure how to expose Harbor service

• Ingress: The ingress controller must be installed in the Kubernetes cluster.
  Notes: if TLS is disabled, the port must be included in the command when pulling/pushing images. Refer to issue #5291 for details.
• 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 client

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

• if service exposed via Ingress, the domain should be the value of expose.ingress.hosts.core
• if service exposed via ClusterIP, the domain should be the value of expose.clusterIP.name
• if service exposed via NodePort, the domain should be the IP address of one Kubernetes node
• if service exposed via LoadBalancer, 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.

Configure how to persist data

• 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 already have 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 other items listed in [configuration](#configuration) section

Install the chart Copy Section

Install the Harbor helm chart with a release name my-release:

helm install my-release harbor/harbor

Uninstallation Copy Chapter

To uninstall/delete the my-release deployment:

helm uninstall my-release

Configuration Copy Chapter

The following table lists the configurable parameters of the Harbor chart and the default values.

2. Official Technical Reference & Guides (goharbor/website) Copy Chapter

File: README.md Copy Chapter

The Harbor website

This repo houses the assets used to build the Harbor website, available at https://goharbor.io.

Tools Copy Chapter

The website is built and developed using the Hugo static site generator.

Instructions for installing Hugo can be found here. Use the version of Hugo specified by the HUGO_VERSION environment variable in the netlify.toml configuration file, and make sure to install the "extended" version of Hugo with support for Hugo Pipes.

backport is used to backport PRs into different release branches.

Website content Copy Chapter

The content for the Harbor blog is in content/blog, while the content for the Harbor documentation is in the docs folder.

The latest (edge) version of the documentation lives in the docs folder on the main branch, and is always viewable on https://goharbor.io/docs/edge. Documentation for specific released versions lives in its own release branch, for example release-2.1.0.

Creating a PR Copy Section

In general, all PRs should be made against the main branch to update the edge version of the docs. If you are making a change that also affects released versions, indicate which release branches to update in your PR so a website maintainer can backport your changes.

If you are making a change that is specific to a single released version of documentation, make a PR against that branch (release-X). For example, if you are fixing something specific to v2.1.0 you should make a PR against the release-2.1.0 branch only. If you are fixing something that impacts v2.1.0 docs and all future versions, you should make the PR against the main branch so the change can also be backported to the v2.1.0 docs.

A preview of your changes is viewable through the Netlify preview linked in the PR tests. Use this to verify that your changes look good before asking the maintainers for a review. When updating the edge version make sure you add /docs/edge/ to the preview URL to see your changes.

Creating release docs Copy Section

When creating docs for a new release, please create a branch with the format release-X.Y.Z.
When you want to make these docs available through the dropdown menu, put the following into the config.toml file, above all other versions (versions are linked based on order in the config file):

[[params.versions]]
harborversion = "X.Y.Z"
helmversion = "1.3"
branchname = "release-X.Y.Z"

As last step, update the _index.md file with the new version number and correct links.

After a release, update the backport tool configuration file, .backportrc.json, with the new release branch name.

CSS Copy Section

The CSS for the site is built from Sass inputs in the assets/sass directory. There is also a small amount of JavaScript logic for the site in assets/js/app.js.

Publishing the website Copy Chapter

The Harbor website is published automatically on the Netlify platform. Whenever changes are merged, the site is re-built and re-deployed, usually within about one minute.

Run the Harbor website locally Copy Chapter

Step 1: Clone project Copy Section

git clone https://github.com/goharbor/website.git
cd website

Step 2: Load documentation content Copy Chapter

The Markdown content for the Harbor docs is drawn from the docs folder and the release-X branches. To pull that content into your local website repo:

make prepare

This copies the docs directory and the release-X branches into this repo's content folder, separated by versions, where it can be processed by Hugo.

Step 3: Install npm dependencies Copy Chapter

npm i

Step 4: Run Hugo in server mode Copy Chapter

make serve

This starts up the local Hugo server on http://localhost:1313. As you make changes, the site refreshes automatically in your browser.

Checking links Copy Chapter

To run the link checker for the Harbor website:

make check-internal-links

This command builds the site (including drafts and future content), downloads the htmltest link checker into your local directory, and runs the checker in accordance with the configuration specified in .htmltest.yml. Only internal links are checked and all errors are piped to stdout.

License Copy Chapter

File: docs/README.md Copy Chapter

Harbor Documentation

This is the main table of contents for the Harbor 2.1.x documentation.

Harbor Installation and Configuration Copy Chapter

This section describes how to install Harbor and perform the required initial configurations. These day 1 operations are performed by the Harbor Administrator.

• Introduction
• Test Harbor with the Demo Server
• Harbor Compatibility List
• Harbor Installation Prerequisites
• Download the Harbor Installer
• Configure HTTPS Access to Harbor
• Configure the Harbor YML File
• Run the Installer Script
• Deploying Harbor with High Availability via Helm
• Troubleshooting Harbor Installation
• Reconfigure Harbor and Manage the Harbor Lifecycle
• Customize the Harbor Token Service
• Configure Harbor Settings at the Command Line

Harbor Administration Copy Chapter

This section describes how to use and maintain Harbor after deployment. These day 2 operations are performed by the Harbor Administrator.

• Introduction
• Configuring Authentication
  • Configure Database Authentication
  • Configure LDAP/Active Directory Authentication
  • Configure OIDC Provider Authentication
• Managing Users
  • User Permissions By Role
  • Create User Accounts in Database Mode
• Configure Global Settings
• Configure Project Quotas
• Configuring Replication
  • Create Replication Endpoints
  • Create Replication Rules
  • Manage Replications
• Vulnerability Scanning
  • Connect Harbor to Additional Vulnerability Scanners
  • Scan Individual Images
  • Scan All Images
  • Schedule Scans
  • Import Vulnerability Data to an Offline Harbor instance
  • Configure System-Wide CVE Allowlists
• Garbage Collection
• Upgrade Harbor and Migrate Data
  • Upgrading Harbor Deployed with Helm
  • Roll Back an Upgrade
  • Test Harbor Upgrade
• Configure P2P Preheat
• User-defined OCI artifact

Working with Harbor Projects Copy Chapter

This section describes how users with the developer, maintainer, and project administrator roles manage and participate in Harbor projects.

• Introduction
• Create Projects
  • Assign Users to a Project
• Project Configuration
  • Access and Search Project Logs
  • Create Robot Accounts
  • Configure Webhook Notifications
  • Configure a Per-Project CVE Allowlist
  • Implementing Content Trust
• Working with Images, Tags, and Helm Charts
  • Pulling and Pushing Images
  • Create Labels
  • Retag Images
  • Create Tag Retention Rules
  • Create Tag Immutability Rules
  • Manage Kubernetes Packages with Helm Charts
  • Preheat Images
• Using API Explorer

Build, Customize, and Contribute to Harbor Copy Chapter

This section describes how developers can build from Harbor source code, customize their deployments, and contribute to the open-source Harbor project.

• Build Harbor from Source Code
• Developing the Harbor Frontend
• Customize the Harbor Look & Feel
• Developing for Internationalization
• Using Make
• View and test Harbor REST API via Swagger
• Registry Landscape
• E2E Test Scripting Guide

See also the list of Articles from the Harbor Community.