mirror of https://github.com/goharbor/harbor.git
Moving docs from the harbor to the website repo
Signed-off-by: jonasrosland <jrosland@vmware.com>
This commit is contained in:
jonasrosland
parent
112e38a080
commit
e7d1563c6b
|
|
@ -1,13 +0,0 @@
|
|||
name: Build and Deploy to Netlify
|
||||
on:
|
||||
push:
|
||||
paths:
|
||||
- 'docs/**'
|
||||
branches:
|
||||
- master
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-18.04
|
||||
steps:
|
||||
- name: Deploy new-site to Netlify
|
||||
run: curl -X POST -d {} ${{ secrets.NETLIFY_BUILD_HOOK }}
|
||||
57
ADOPTERS.md
57
ADOPTERS.md
|
|
@ -1,4 +1,5 @@
|
|||
# Harbor Adopters
|
||||
|
||||
Below is a list of adopters of Harbor in **production environments** that have
|
||||
publicly shared the details of their usage as well as the benefits provided by
|
||||
Harbor that their business relies on. There are some unreferenceable users that
|
||||
|
|
@ -8,34 +9,35 @@ publicly at this time.
|
|||
There are many additional adopters of Harbor in the evaluating phase that will
|
||||
be added to this list as they transition to production deployments.
|
||||
|
||||
<a href="https://www.jd.com" border="0" target="_blank"><img alt="JD.com" src="docs/img/adopters/jd.png" height="50"></a>
|
||||
<a href="https://www.trendmicro.com" border="0" target="_blank"><img alt="trendmicro" src="docs/img/adopters/trendmicro.png" height="50"></a>
|
||||
<a href="https://www.datayes.com" border="0" target="_blank"><img alt="DataYes" src="docs/img/adopters/datayes.png" height="50"></a>
|
||||
<a href="https://www.axatp.com" border="0" target="_blank"><img alt="axatp" src="docs/img/adopters/axatp.png" height="50"></a> <br/><br/>
|
||||
<a href="https://www.360totalsecurity.com/en/" target="_blank" border="0"><img alt="360 Total Security" src="docs/img/adopters/360.png" height="50"></a>
|
||||
<a href="https://www.talkingdata.com" border="0" target="_blank"><img alt="talkingdata" src="docs/img/adopters/talkingdata.png" height="40"></a>
|
||||
<a href="http://www.boericasa.com/index.html" border="0" target="_blank"><img alt="BoerSmart" src="docs/img/adopters/boer.png" height="50"></a>
|
||||
<a href="http://www.open.com.cn" border="0" target="_blank"><img alt="OpenEdutainment" src="docs/img/adopters/openedutainment.png" height="70"></a>
|
||||
<a href="http://www.ifre.com.cn" border="0" target="_blank"><img alt="iFRE" src="docs/img/adopters/ifre.png" height="50"></a> <br/><br/>
|
||||
<a href="http://www.boco.com.cn:8080/bocoit/" border="0" target="_blank"><img alt="BOCOIT" src="docs/img/adopters/bocoit.png" height="50"></a>
|
||||
<a href="http://www.wise2c.com/" border="0" target="_blank"><img alt="wise2c" src="docs/img/adopters/wise2c.png" height="50"></a>
|
||||
<a href="http://www.hydsoft.com/" border="0" target="_blank"><img alt="HYDSoft" src="docs/img/adopters/hydsoft.png" height="50"></a>
|
||||
<a href="http://www.cloud-star.com.cn/" border="0" target="_blank"><img alt="CloudStar" src="docs/img/adopters/cloudstar.png" height="50"></a>
|
||||
<a href="http://www.beyondsoft.com/" border="0" target="_blank"><img alt="BeyondSoft" src="docs/img/adopters/beyondsoft.png" height="50"></a>
|
||||
<a href="http://www.chinamobileltd.com/" border="0" target="_blank"><img alt="ChinaMobile" src="docs/img/adopters/china-mobile.png" height="50"></a>
|
||||
<a href="https://www.caicloud.io" target="_blank" border="0"><img alt="CaiCloud" src="docs/img/adopters/caicloud.png" height="50"></a>
|
||||
<a href="https://rancher.com/" target="_blank" border="0"><img alt="Rancher" src="docs/img/adopters/rancher.png" height="50"></a>
|
||||
<a href="https://www.tenxcloud.com/" target="_blank" border="0"><img alt="TenxCloud" src="docs/img/adopters/tenxcloud.png" height="70"></a>
|
||||
<a href="http://www.bingocc.com/" target="_blank" border="0"><img alt="BingoCloud" src="docs/img/adopters/bingocloud.png" height="50"></a>
|
||||
<a href="https://www.jd.com" border="0" target="_blank"><img alt="JD.com" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/jd.png" height="50"></a>
|
||||
<a href="https://www.trendmicro.com" border="0" target="_blank"><img alt="trendmicro" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/trendmicro.png" height="50"></a>
|
||||
<a href="https://www.datayes.com" border="0" target="_blank"><img alt="DataYes" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/datayes.png" height="50"></a>
|
||||
<a href="https://www.axatp.com" border="0" target="_blank"><img alt="axatp" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/axatp.png" height="50"></a> <br/><br/>
|
||||
<a href="https://www.360totalsecurity.com/en/" target="_blank" border="0"><img alt="360 Total Security" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/360.png" height="50"></a>
|
||||
<a href="https://www.talkingdata.com" border="0" target="_blank"><img alt="talkingdata" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/talkingdata.png" height="40"></a>
|
||||
<a href="http://www.boericasa.com/index.html" border="0" target="_blank"><img alt="BoerSmart" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/boer.png" height="50"></a>
|
||||
<a href="http://www.open.com.cn" border="0" target="_blank"><img alt="OpenEdutainment" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/openedutainment.png" height="70"></a>
|
||||
<a href="http://www.ifre.com.cn" border="0" target="_blank"><img alt="iFRE" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/ifre.png" height="50"></a> <br/><br/>
|
||||
<a href="http://www.boco.com.cn:8080/bocoit/" border="0" target="_blank"><img alt="BOCOIT" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/bocoit.png" height="50"></a>
|
||||
<a href="http://www.wise2c.com/" border="0" target="_blank"><img alt="wise2c" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/wise2c.png" height="50"></a>
|
||||
<a href="http://www.hydsoft.com/" border="0" target="_blank"><img alt="HYDSoft" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/hydsoft.png" height="50"></a>
|
||||
<a href="http://www.cloud-star.com.cn/" border="0" target="_blank"><img alt="CloudStar" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/cloudstar.png" height="50"></a>
|
||||
<a href="http://www.beyondsoft.com/" border="0" target="_blank"><img alt="BeyondSoft" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/beyondsoft.png" height="50"></a>
|
||||
<a href="http://www.chinamobileltd.com/" border="0" target="_blank"><img alt="ChinaMobile" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/china-mobile.png" height="50"></a>
|
||||
<a href="https://www.caicloud.io" target="_blank" border="0"><img alt="CaiCloud" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/caicloud.png" height="50"></a>
|
||||
<a href="https://rancher.com/" target="_blank" border="0"><img alt="Rancher" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/rancher.png" height="50"></a>
|
||||
<a href="https://www.tenxcloud.com/" target="_blank" border="0"><img alt="TenxCloud" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/tenxcloud.png" height="70"></a>
|
||||
<a href="http://www.bingocc.com/" target="_blank" border="0"><img alt="BingoCloud" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/bingocloud.png" height="50"></a>
|
||||
<br/><br/>
|
||||
<a href="http://www.slamtec.com" target="_blank" border="0"><img alt="SlamTec" src="docs/img/adopters/slamtec.png" height="50"></a>
|
||||
<a href="http://www.cloudchef.io/" target="_blank" border="0"><img alt="CloudChef" src="docs/img/adopters/cloudchef.png" height="50"></a>
|
||||
<a href="https://pivotal.io/" target="_blank" border="0"><img alt="Pivotal" src="docs/img/adopters/pivotal.png" height="40"></a>
|
||||
<a href="https://www.163yun.com" target="_blank" border="0"><img alt="Netease Cloud" src="docs/img/adopters/wangyi.png" height="50"></a>
|
||||
<a href="http://www.yanrongyun.com" target="_blank" border="0"><img alt="Yanrongyun" src="docs/img/adopters/Yanrong.jpg" height="40"></a>
|
||||
<a href="https://anchore.com" target="_blank" border="0"><img alt="Anchore" src="docs/img/adopters/anchore_logo.png" height="40"></a>
|
||||
<a href="http://www.slamtec.com" target="_blank" border="0"><img alt="SlamTec" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/slamtec.png" height="50"></a>
|
||||
<a href="http://www.cloudchef.io/" target="_blank" border="0"><img alt="CloudChef" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/cloudchef.png" height="50"></a>
|
||||
<a href="https://pivotal.io/" target="_blank" border="0"><img alt="Pivotal" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/pivotal.png" height="40"></a>
|
||||
<a href="https://www.163yun.com" target="_blank" border="0"><img alt="Netease Cloud" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/wangyi.png" height="50"></a>
|
||||
<a href="http://www.yanrongyun.com" target="_blank" border="0"><img alt="Yanrongyun" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/Yanrong.jpg" height="40"></a>
|
||||
<a href="https://anchore.com" target="_blank" border="0"><img alt="Anchore" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/adopters/anchore_logo.png" height="40"></a>
|
||||
|
||||
## Success Stories
|
||||
|
||||
**JD.com:** Harbor is the registry service of JD.com’s JDOS
|
||||
platform. Harbor has been used for over 2 years in production with tens of
|
||||
thousands of nodes and managing millions of container images.
|
||||
|
|
@ -82,5 +84,6 @@ feature within Harbor before deploying images into production.
|
|||
and scan customized container images for different business applications, like
|
||||
ELK stack, as part of their CI/CD pipeline.
|
||||
|
||||
# Adding a logo
|
||||
If you would like to add your logo to the `Users and Partners of Harbor` section of the website, add a PNG version of your logo to the docs/img/adopters directory in this repo and submit a pull request with your change. Name the image file something that reflects your company (e.g., if your company is called Acme, name the image acme.png). We will follow up and make the change in the goharbor.io website as well.
|
||||
## Adding your logo
|
||||
|
||||
If you would like to add your logo here and to the `Users and Partners of Harbor` section of the website, add a PNG or SVG version of your logo to the [adopters](https://github.com/goharbor/website/tree/master/docs/img/adopters) directory of the [website](https://github.com/goharbor/website) and submit a pull request with your change. Name the image file something that reflects your company (e.g., if your company is called Acme, name the image acme.png). We will follow up and make the change in the goharbor.io website as well.
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ git fetch $USER
|
|||
```
|
||||
**NOTES:** Note that GOPATH can be any directory, the example above uses $HOME/go. Change $USER above to your own GitHub username.
|
||||
|
||||
To build the project, please refer the [build](docs/build-customize-contribute/compile-guide.md) guideline.
|
||||
To build the project, please refer the [build](https://goharbor.io/docs/2.0.0/build-customize-contribute/compile-guide/) guideline.
|
||||
|
||||
### Repository Structure
|
||||
|
||||
|
|
@ -52,7 +52,6 @@ Here is the basic structure of the harbor code base. Some of the key folders / f
|
|||
.
|
||||
...
|
||||
├── contrib # Contain documents, scripts, and other helpful things which are contributed by the community
|
||||
├── docs # Keep documents here
|
||||
├── make # Resource for building and setting up Harbor environment
|
||||
...
|
||||
├── src # Source code folder
|
||||
|
|
@ -170,8 +169,7 @@ cd $REPO_DIR/src/portal/lib
|
|||
npm install
|
||||
```
|
||||
|
||||
|
||||
To run the code, please refer to the [build](docs/compile_guide.md) guideline.
|
||||
To run the code, please refer to the [build](https://goharbor.io/docs/2.0.0/build-customize-contribute/compile-guide/) guideline.
|
||||
|
||||
## Contribute Workflow
|
||||
|
||||
|
|
@ -181,9 +179,6 @@ Please submit a PR broken down into small changes bit by bit. A PR consisting of
|
|||
|
||||
Note: If you split your pull request to small changes, please make sure any of the changes goes to master will not break anything. Otherwise, it can not be merged until this feature complete.
|
||||
|
||||
The graphic shown below describes the overall workflow about how to contribute code to Harbor repository.
|
||||
|
||||
|
||||
### Fork and clone
|
||||
|
||||
Fork the Harbor repository and clone the code to your local workspace. Per Go's [workspace instructions](https://golang.org/doc/code.html#Workspaces), place Harbor's code on your `GOPATH`. Refer to section [Fork Repository](#fork-repository) for details.
|
||||
|
|
@ -252,7 +247,7 @@ Run UI library test cases:
|
|||
npm run test
|
||||
```
|
||||
|
||||
To build the code, please refer to [build](docs/build-customize-contribute/compile-guide.md) guideline.
|
||||
To build the code, please refer to [build](https://goharbor.io/docs/2.0.0/build-customize-contribute/compile-guide/) guideline.
|
||||
|
||||
### Keep sync with upstream
|
||||
|
||||
|
|
@ -336,9 +331,9 @@ Be sure to include the steps to reproduce the problem if applicable. It can help
|
|||
|
||||
Update the documentation if you are creating or changing features. Good documentation is as important as the code itself.
|
||||
|
||||
The main location for the document is the `docs/` folder. The images referred in documents can be placed in `docs/img`.
|
||||
The main location for the documentation is the [website repository](https://github.com/goharbor/website). The images referred to in documents can be placed in `docs/img` in that repo.
|
||||
|
||||
Documents are written with Markdown text. See [Writing on GitHub](https://help.github.com/categories/writing-on-github/) for more details.
|
||||
Documents are written with Markdown. See [Writing on GitHub](https://help.github.com/categories/writing-on-github/) for more details.
|
||||
|
||||
## Design new features
|
||||
|
||||
|
|
|
|||
22
README.md
22
README.md
|
|
@ -10,7 +10,7 @@
|
|||
|
||||
</br>
|
||||
|
||||
|Community Meeting|
|
||||
|Community Meeting|
|
||||
|------------------|
|
||||
|The Harbor Project holds bi-weekly community calls in two different timezones. To join the community calls or to watch previous meeting notes and recordings, please visit the [meeting schedule](https://github.com/goharbor/community/blob/master/MEETING_SCHEDULE.md).|
|
||||
|
||||
|
|
@ -19,7 +19,7 @@
|
|||
**Note**: The `master` branch may be in an *unstable or even broken state* during development.
|
||||
Please use [releases](https://github.com/vmware/harbor/releases) instead of the `master` branch in order to get a stable set of binaries.
|
||||
|
||||
<img alt="Harbor" src="docs/img/readme/harbor_logo.png">
|
||||
<img alt="Harbor" src="https://raw.githubusercontent.com/goharbor/website/master/docs/img/readme/harbor_logo.png">
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ Harbor is hosted by the [Cloud Native Computing Foundation](https://cncf.io) (CN
|
|||
* **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. A Harbor Operator was added recently as well - https://goharbor.io/docs/1.10/build-customize-contribute/e2e_api_python_based_scripting_guide/
|
||||
* **Easy deployment**: Harbor can be deployed via Docker compose as well Helm Chart. A Harbor Operator was added recently as well - https://goharbor.io/docs/2.0.0/build-customize-contribute/e2e_api_python_based_scripting_guide/
|
||||
|
||||
## Architecture
|
||||
|
||||
|
|
@ -57,11 +57,11 @@ For learning the architecture design of Harbor, check the document [Architecture
|
|||
|
||||
**On a Linux host:** docker 17.06.0-ce+ and docker-compose 1.18.0+ .
|
||||
|
||||
Download binaries of **[Harbor release ](https://github.com/vmware/harbor/releases)** and follow **[Installation & Configuration Guide](docs/install-config/_index.md)** to install Harbor.
|
||||
Download binaries of **[Harbor release ](https://github.com/vmware/harbor/releases)** and follow **[Installation & Configuration Guide](https://goharbor.io/docs/2.0.0/install-config/)** to install Harbor.
|
||||
|
||||
If you want to deploy Harbor on Kubernetes, please use the **[Harbor chart](https://github.com/goharbor/harbor-helm)**.
|
||||
|
||||
Refer to **[User Guide](docs/user_guide.md)** for more details on how to use Harbor.
|
||||
Refer to the **[documentation](https://goharbor.io/docs/)** for more details on how to use Harbor.
|
||||
|
||||
## OCI Distribution Conformance Tests
|
||||
|
||||
|
|
@ -69,11 +69,11 @@ Check the OCI distribution conformance tests [report](https://storage.googleapis
|
|||
|
||||
## Compatibility
|
||||
|
||||
The [compatibility list](./docs/install-config/harbor-compatibility-list.md) document provides compatibility information for the Harbor components.
|
||||
The [compatibility list](https://goharbor.io/docs/2.0.0/install-config/harbor-compatibility-list/) document provides compatibility information for the Harbor components.
|
||||
|
||||
* [Replication adapters](./docs/install-config/harbor-compatibility-list.md#Replication-Adapters)
|
||||
* [OIDC adapters](./docs/install-config/harbor-compatibility-list.md#OIDC-Adapters)
|
||||
* [Scanner adapters](./docs/install-config/harbor-compatibility-list.md#Scanner-Adapters)
|
||||
* [Replication adapters](https://goharbor.io/docs/2.0.0/install-config/harbor-compatibility-list/#replication-adapters)
|
||||
* [OIDC adapters](https://goharbor.io/docs/2.0.0/install-config/harbor-compatibility-list/#oidc-adapters)
|
||||
* [Scanner adapters](https://goharbor.io/docs/2.0.0/install-config/harbor-compatibility-list/#scanner-adapters)
|
||||
|
||||
## Community
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ The [compatibility list](./docs/install-config/harbor-compatibility-list.md) doc
|
|||
|
||||
## Demos
|
||||
|
||||
* **[Live Demo](https://demo.goharbor.io)** - A demo environment with the latest Harbor stable build installed. For additional information please refer to [this page](docs/demo_server.md).
|
||||
* **[Live Demo](https://demo.goharbor.io)** - A demo environment with the latest Harbor stable build installed. For additional information please refer to [this page](https://goharbor.io/docs/2.0.0/install-config/demo-server/).
|
||||
* **[Video Demos](https://github.com/goharbor/harbor/wiki/Video-demos-for-Harbor)** - Demos for Harbor features and continuously updated.
|
||||
|
||||
## Partners and Users
|
||||
|
|
@ -95,7 +95,7 @@ For a list of users, please refer to [ADOPTERS.md](ADOPTERS.md).
|
|||
|
||||
### Security Audit
|
||||
|
||||
A third party security audit was performed by Cure53 in October of 2019. You can see the full report [here](docs/security/Harbor_Security_Audit_Oct2019.pdf).
|
||||
A third party security audit was performed by Cure53 in October of 2019. You can see the full report [here](https://goharbor.io/docs/2.0.0/security/Harbor_Security_Audit_Oct2019.pdf).
|
||||
|
||||
### Reporting security vulnerabilities
|
||||
|
||||
|
|
|
|||
Binary file not shown.
Binary file not shown.
|
|
@ -1,90 +1,5 @@
|
|||
Harbor Documentation
|
||||
# Harbor Documentation
|
||||
|
||||
This is the main table of contents for the Harbor 1.10.x documentation.
|
||||
All Harbor documentation is presented on [goharbor.io/docs](https://goharbor.io/docs).
|
||||
|
||||
## Harbor Installation and Configuration
|
||||
|
||||
This section describes how to install Harbor and perform the required initial configurations. These day 1 operations are performed by the Harbor Administrator.
|
||||
|
||||
- [Introduction](install-config/_index.md)
|
||||
- [Test Harbor with the Demo Server](install-config/demo-server.md)
|
||||
- [Harbor Compatibility List](install-config/harbor-compatibility-list.md)
|
||||
- [Harbor Installation Prerequisites](install-config/installation-prereqs.md)
|
||||
- [Download the Harbor Installer](install-config/download-installer.md)
|
||||
- [Configure HTTPS Access to Harbor](install-config/configure-https.md)
|
||||
- [Configure the Harbor YML File](install-config/configure-yml-file.md)
|
||||
- [Run the Installer Script](install-config/run-installer-script.md)
|
||||
- [Deploying Harbor with High Availability via Helm](install-config/harbor-ha-helm.md)
|
||||
- [Deploy Harbor with the Quick Installation Script](install-config/quick-install-script.md)
|
||||
- [Troubleshooting Harbor Installation](install-config/troubleshoot-installation.md)
|
||||
- [Reconfigure Harbor and Manage the Harbor Lifecycle](install-config/reconfigure-manage-lifecycle.md)
|
||||
- [Customize the Harbor Token Service](install-config/customize-token-service.md)
|
||||
- [Configure Harbor User Settings at the Command Line](install-config/configure-user-settings-cli.md)
|
||||
|
||||
## Harbor Administration
|
||||
|
||||
This section describes how to use and maintain Harbor after deployment. These day 2 operations are performed by the Harbor Administrator.
|
||||
|
||||
- [Introduction](administration/_index.md)
|
||||
- [Configuring Authentication](administration/configure-authentication/_index.md)
|
||||
- [Configure Database Authentication](administration/configure-authentication/db-auth.md)
|
||||
- [Configure LDAP/Active Directory Authentication](administration/configure-authentication/ldap-auth.md)
|
||||
- [Configure OIDC Provider Authentication](administration/configure-authentication/oidc-auth.md)
|
||||
- [Managing Users](administration/managing-users/_index.md)
|
||||
- [User Permissions By Role](administration/managing-users/user-permissions-by-role.md)
|
||||
- [Create User Accounts in Database Mode](administration/managing-users/create-users-db.md)
|
||||
- [Configure Global Settings](administration/general-settings/_index.md)
|
||||
- [Configure Project Quotas](administration/configure-project-quotas/_index.md)
|
||||
- [Configuring Replication](administration/configuring-replication/_index.md)
|
||||
- [Create Replication Endpoints](administration/configuring-replication/create-replication-endpoints.md)
|
||||
- [Create Replication Rules](administration/configuring-replication/create-replication-rules.md)
|
||||
- [Manage Replications](administration/configuring-replication/manage-replications.md)
|
||||
- [Vulnerability Scanning](administration/vulnerability-scanning/_index.md)
|
||||
- [Connect Harbor to Additional Vulnerability Scanners](administration/vulnerability-scanning/pluggable-scanners.md)
|
||||
- [Scan Individual Images](administration/vulnerability-scanning/scan-individual-image.md)
|
||||
- [Scan All Images](administration/vulnerability-scanning/scan-all-images.md)
|
||||
- [Schedule Scans](administration/vulnerability-scanning/schedule-scans.md)
|
||||
- [Import Vulnerability Data to an Offline Harbor instance](administration/vulnerability-scanning/import-vulnerability-data.md)
|
||||
- [Configure System-Wide CVE Allowlists](administration/vulnerability-scanning/configure-system-allowlist.md)
|
||||
- [Garbage Collection](administration/garbage-collection/_index.md)
|
||||
- [Upgrade Harbor and Migrate Data](administration/upgrade/upgrade-migrate-data.md)
|
||||
- [Upgrading Harbor Deployed with Helm](administration/upgrade/helm-upgrade.md)
|
||||
- [Roll Back an Upgrade](administration/upgrade/roll-back-upgrade.md)
|
||||
- [Test Harbor Upgrade](administration/upgrade/upgrade-test.md)
|
||||
|
||||
## Working with Harbor Projects
|
||||
|
||||
This section describes how users with the developer, master, and project administrator roles manage and participate in Harbor projects.
|
||||
|
||||
- [Introduction](working-with-projects/_index.md)
|
||||
- [Create Projects](working-with-projects/create-projects/_index.md)
|
||||
- [Assign Users to a Project](working-with-projects/add-users.md)
|
||||
- [Project Configuration](working-with-projects/project-configuration/_index.md)
|
||||
- [Access and Search Project Logs](working-with-projects/access-project-logs.md)
|
||||
- [Create Robot Accounts](working-with-projects/create-robot-accounts.md)
|
||||
- [Configure Webhook Notifications](working-with-projects/configure-webhooks.md)
|
||||
- [Configure a Per-Project CVE Allowlist](working-with-projects/configure-project-allowlist.md)
|
||||
- [Implementing Content Trust](working-with-projects/implementing-content-trust.md)
|
||||
- [Working with Images, Tags, and Helm Charts](working-with-projects/working-with-images.md)
|
||||
- [Pulling and Pushing Images](working-with-projects/pulling-pushing-images.md)
|
||||
- [Create Labels](working-with-projects/create-labels.md)
|
||||
- [Retag Images](working-with-projects/retagging-images.md)
|
||||
- [Create Tag Retention Rules](working-with-projects/create-tag-retention-rules.md)
|
||||
- [Create Tag Immutability Rules](working-with-projects/create-tag-immutability-rules.md)
|
||||
- [Manage Kubernetes Packages with Helm Charts](working-with-projects/managing-helm-charts.md)
|
||||
- [Using API Explorer](working-with-projects/using-api-explorer/_index.md)
|
||||
|
||||
## Build, Customize, and Contribute to Harbor
|
||||
|
||||
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](build-customize-contribute/compile-guide.md)
|
||||
- [Developing the Harbor Frontend](build-customize-contribute/ui-contribution-get-started.md)
|
||||
- [Customize the Harbor Look & Feel ](build-customize-contribute/customize-look-feel.md)
|
||||
- [Developing for Internationalization](build-customize-contribute/developer-guide-i18n.md)
|
||||
- [Using Make](build-customize-contribute/use-make.md)
|
||||
- [View and test Harbor REST API via Swagger](build-customize-contribute/configure-swagger.md)
|
||||
- [Registry Landscape](build-customize-contribute/registry-landscape.md)
|
||||
- [E2E Test Scripting Guide](build-customize-contribute/e2e_api_python_based_scripting_guide.md)
|
||||
|
||||
See also the list of [Articles from the Harbor Community](https://github.com/goharbor/harbor/blob/master/docs/README.md#articles-from-the-community).
|
||||
To contribute to the documentation, please head over to the [website repository](https://github.com/goharbor/website).
|
||||
|
|
|
|||
|
|
@ -1,27 +0,0 @@
|
|||
---
|
||||
title: Harbor 2.0 Documentation
|
||||
---
|
||||
|
||||
Welcome to the Harbor 2.0.x documentation. This documentation includes all of the information that you need to install, configure, and use Harbor.
|
||||
|
||||
## Harbor Installation and Configuration
|
||||
|
||||
This section describes how to install Harbor and perform the required initial configuration. These day 1 operations are performed by the Harbor Administrator. [Read more](install-config/_index.md)
|
||||
|
||||
## Harbor Administration
|
||||
|
||||
This section describes how to use and maintain your Harbor registry instance after deployment. These day 2 operations are performed by the Harbor Administrator. [Read more](administration/_index.md)
|
||||
|
||||
## Working with Harbor Projects
|
||||
|
||||
This section describes how users with the developer, master, and project administrator roles manage users, and create, configure, and participate in Harbor projects. [Read more](working-with-projects/_index.md)
|
||||
|
||||
## Building, Customizing, and Contributing to Harbor
|
||||
|
||||
This section describes how developers can build from Harbor source code, customize their deployments, and contribute to the open-source Harbor project. [Read more](build-customize-contribute/_index.md)
|
||||
|
||||
## Access the Documentation Source Files
|
||||
|
||||
The source files for this documentation set are located in the [Harbor repository on Github](https://github.com/goharbor/harbor/tree/release-2.0.0/docs).
|
||||
|
||||
For versions of the docs before 2.0.x, go to the [`docs` folder in the Github repository](https://github.com/goharbor/harbor/tree/master/docs) and select the appropriate `release-1.xx.x` branch.
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
---
|
||||
title: Harbor Administration
|
||||
weight: 10
|
||||
---
|
||||
|
||||
This section describes how to configure and maintain Harbor after deployment. These operations are performed by the Harbor system administrator. The Harbor system administrator performs global configuration operations that apply to the whole Harbor instance.
|
||||
|
||||
The operations that are performed by the Harbor system administrator are the following.
|
||||
|
||||
- Select database, LDAP/Active Directory, or OIDC based authentication. For information, see [Configuring Authentication](configure-authentication).
|
||||
- Add users in database authentication mode and assign the system administrator role to other users. For information, see [Managing Users](managing-users).
|
||||
- Configure global settings, such as configuring an email server, setting the registry to read-only mode, and restriction who can create projects. For information, see [Configure Global Settings](general-settings).
|
||||
- Apply resource quotas to projects. For information, see [Configure Project Quotas](configure-project-quotas).
|
||||
- Set up replication of images between Harbor and another Harbor instance or a 3rd party replication target. For information, see [Configuring Replication](configuring-replication).
|
||||
- Set up vulnerability scanners to check the images in the registry for CVE vulnerabilities. For information, see [Vulnerability Scanning](vulnerability-scanning).
|
||||
- Perform garbage collection, to remove unnecessary data from Harbor. For information, see [Garbage Collection](garbage-collection).
|
||||
- Upgrade Harbor when a new version becomes available. For information, see [Upgrading Harbor](upgrade/upgrade-migrate-data.md).
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
---
|
||||
title: Configuring Authentication
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Harbor supports different modes for authenticating users and managing user accounts. You should select an authentication mode as soon as you deploy Harbor.
|
||||
|
||||
{{< important >}}
|
||||
If you create user accounts in the Harbor database, Harbor is locked in database mode. You cannot change to a different authentication mode after you have created local users.
|
||||
{{< /important >}}
|
||||
|
||||
- [Database Authentication](db-auth.md): You create and manage user accounts directly in Harbor. The user accounts are stored in the Harbor database.
|
||||
- [LDAP/Active Directory Authentication](ldap-auth.md): You connect Harbor to an external LDAP/Active Directory server. The user accounts are created and managed by your LDAP/AD provider.
|
||||
- [OIDC Provider Authentication](oidc-auth.md): You connect Harbor to an external OIDC provider. The user accounts are created and managed by your OIDC provider.
|
||||
|
||||
The Harbor interface offers an option to configure UAA authentication. This authentication mode is not recommended and is not documented in this guide.
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
title: Configure Database Authentication
|
||||
weight: 15
|
||||
---
|
||||
|
||||
In database authentication mode, user accounts are stored in the local database. By default, only the Harbor system administrator can create user accounts to add users to Harbor. You can optionally configure Harbor to allow self-registration.
|
||||
|
||||
{{< important >}}
|
||||
If you create users in the database, Harbor is locked in database mode. You cannot change to a different authentication mode after you have created local users.
|
||||
{{< /important >}}
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Under **Administration**, go to **Configuration** and select the **Authentication** tab.
|
||||
1. Leave **Auth Mode** set to the default **Database** option.
|
||||
|
||||
|
||||
|
||||
1. Optionally select the **Allow Self-Registration** check box.
|
||||
|
||||
|
||||
|
||||
If you enable the self registration option, users can register themselves in Harbor. Self-registration is disabled by default. If you enable self-registration, unregistered users can sign up for a Harbor account by clicking **Sign up for an account** in the Harbor log in page.
|
||||
|
||||
|
||||
|
||||
## What to Do Next
|
||||
|
||||
For information about how to create users in database authentication mode, see [Create User Accounts in Database Mode](../managing-users/create-users-db.md).
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
---
|
||||
title: Configure LDAP/Active Directory Authentication
|
||||
weight: 20
|
||||
---
|
||||
|
||||
If you select LDAP/AD authentication, users whose credentials are stored in an external LDAP or AD server can log in to Harbor directly. In this case, you do not create user accounts in Harbor.
|
||||
|
||||
{{< important >}}
|
||||
You can change the authentication mode from database to LDAP only if no local users have been added to the database. If there is at least one user other than `admin` in the Harbor database, you cannot change the authentication mode.
|
||||
{{< /important >}}
|
||||
|
||||
Because the users are managed by LDAP or AD, self-registration, creating users, deleting users, changing passwords, and resetting passwords are not supported in LDAP/AD authentication mode.
|
||||
|
||||
If you want to manage user authentication by using LDAP groups, you must enable the `memberof` feature on the LDAP/AD server. With the `memberof` feature, the LDAP/AD user entity's `memberof` attribute is updated when the group entity's `member` attribute is updated, for example by adding or removing an LDAP/AD user from the LDAP/AD group. This feature is enabled by default in Active Directory. For information about how to enable and verify `memberof` overlay in OpenLDAP, see [this technical note](https://technicalnotes.wordpress.com/2014/04/19/openldap-setup-with-memberof-overlay).
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Under **Administration**, go to **Configuration** and select the **Authentication** tab.
|
||||
1. Use the **Auth Mode** drop-down menu to select **LDAP**.
|
||||
|
||||
|
||||
1. Enter the address of your LDAP server, for example `ldaps://10.162.16.194`.
|
||||
1. Enter information about your LDAP server.
|
||||
|
||||
- **LDAP Search DN** and **LDAP Search Password**: When a user logs in to Harbor with their LDAP username and password, Harbor uses these values to bind to the LDAP/AD server. For example, `cn=admin,dc=example.com`.
|
||||
- **LDAP Base DN**: Harbor looks up the user under the LDAP Base DN entry, including the subtree. For example, `dc=example.com`.
|
||||
- **LDAP Filter**: The filter to search for LDAP/AD users. For example, `objectclass=user`.
|
||||
- **LDAP UID**: An attribute, for example `uid`, or `cn`, that is used to match a user with the username. If a match is found, the user's password is verified by a bind request to the LDAP/AD server.
|
||||
- **LDAP Scope**: The scope to search for LDAP/AD users. Select from **Subtree**, **Base**, and **OneLevel**.
|
||||
|
||||
|
||||
1. If you want to manage user authentication with LDAP groups, configure the group settings.
|
||||
- **LDAP Group Base DN**: The base DN from which to lookup a group in LDAP/AD. For example, `ou=groups,dc=example,dc=com`.
|
||||
- **LDAP Group Filter**: The filter to search for LDAP/AD groups. For example, `objectclass=groupOfNames`.
|
||||
- **LDAP Group GID**: The attribute used to name an LDAP/AD group. For example, `cn`.
|
||||
- **LDAP Group Admin DN**: All LDAP/AD users in this group DN have Harbor system administrator privileges.
|
||||
- **LDAP Group Membership**: The user attribute usd to identify a user as a member of a group. By default this is `memberof`.
|
||||
- **LDAP Scope**: The scope to search for LDAP/AD groups. Select from **Subtree**, **Base**, and **OneLevel**.
|
||||
|
||||
|
||||
1. Uncheck **LDAP Verify Cert** if the LDAP/AD server uses a self-signed or untrusted certificate.
|
||||
|
||||
|
||||
1. Click **Test LDAP Server** to make sure that your configuration is correct.
|
||||
1. Click **Save** to complete the configuration.
|
||||
|
|
@ -1,97 +0,0 @@
|
|||
---
|
||||
title: Configure OIDC Provider Authentication
|
||||
weight: 25
|
||||
---
|
||||
|
||||
If you select OpenID Connect (OIDC) authentication, users log in to the Harbor interface via an OIDC single sign-on (SSO) provider, such as Okta, KeyCloak, or dex. In this case, you do not create user accounts in Harbor.
|
||||
|
||||
{{< important >}}
|
||||
You can change the authentication mode from database to OIDC only if no local users have been added to the database. If there is at least one user other than `admin` in the Harbor database, you cannot change the authentication mode.
|
||||
{{< /important >}}
|
||||
|
||||
Because the users are managed by the OIDC provider, self-registration, creating users, deleting users, changing passwords, and resetting passwords are not supported in OIDC authentication mode.
|
||||
|
||||
### Configure Your OIDC Provider
|
||||
|
||||
You must configure your OIDC provider so that you can use it with Harbor. For precise information about how to perform these configurations, see the documentation for your OIDC provider.
|
||||
|
||||
- Set up the users and groups that will use the OIDC provider to log in to Harbor. You do not need to assign any specific OIDC roles to users or groups as these do not get mapped to Harbor roles.
|
||||
- The URL of the OIDC provider endpoint, known as the Authorization Server in OAuth terminology, must service the well-known URI for its configuration document. For more information about the configuration document, see the [OpenID documentation](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest).
|
||||
- To manage users by using OIDC groups, create a custom group claim that contains all of the user groups that you want to register in Harbor. The group claim must be mapped in the ID token that is sent to Harbor when users log in. You can enable the `memberof` feature on the OIDC provider. With the `memberof` feature, the OIDC user entity's `memberof` attribute is updated when the group entity's `member` attribute is updated, for example by adding or removing an OIDC user from the OIDC group.
|
||||
- Register Harbor as a client application with the OIDC provider. Associate Harbor's callback URI to the client application as a `redirectURI`. This is the address to which the OIDC provider sends ID tokens.
|
||||
|
||||
### Configure an OIDC Provider in Harbor
|
||||
|
||||
Before configuring an OIDC provider in Harbor, make sure that your provider is configured correctly according to the preceding section.
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Under **Administration**, go to **Configuration** and select the **Authentication** tab.
|
||||
1. Use the **Auth Mode** drop-down menu to select **OIDC**.
|
||||
|
||||
|
||||
1. Enter information about your OIDC provider.
|
||||
|
||||
- **OIDC Provider Name**: The name of the OIDC provider.
|
||||
- **OIDC Provider Endpoint**: The URL of the endpoint of the OIDC provider.
|
||||
- **OIDC Client ID**: The client ID with which Harbor is registered as client application with the OIDC provider.
|
||||
- **OIDC Client Secret**: The secret for the Harbor client application.
|
||||
- **Group Claim Name**: The name of a custom group claim that you have configured in your OIDC provider, that includes the groups to add to Harbor.
|
||||
- **OIDC Scope**: A comma-separated string listing the scopes to be used during authentication.
|
||||
|
||||
The OIDC scope must contain `openid` and usually also contains `profile` and `email`. To obtain refresh tokens it should also contain `offline_access`. If you are using OIDC groups, a scope must identify the group claim. Check with your OIDC provider administrator for precise details of how to identify the group claim scope, as this differs from vendor to vendor.
|
||||
|
||||
|
||||
1. Uncheck **Verify Certificate** if the OIDC Provider uses a self-signed or untrusted certificate.
|
||||
1. Verify that the Redirect URI that you configured in your OIDC provider is the same as the one displayed at the bottom of the page.
|
||||
|
||||
|
||||
1. Click **Test OIDC Server** to make sure that your configuration is correct.
|
||||
1. Click **Save** to complete the configuration.
|
||||
|
||||
### Log In to Harbor via an OIDC Provider
|
||||
|
||||
When the Harbor system administrator has configured Harbor to authenticate via OIDC a **Login via OIDC Provider** button appears on the Harbor login page.
|
||||
|
||||
|
||||
|
||||
**NOTE:** When Harbor is configured authentication via OIDC, the **Username** and **Password** fields are reserved for the local Harbor system administrator to log in.
|
||||
|
||||
1. As a Harbor user, click the **Login via OIDC Provider** button.
|
||||
|
||||
This redirects you to the OIDC Provider for authentication.
|
||||
1. If this is the first time that you are logging in to Harbor with OIDC, specify a user name for Harbor to associate with your OIDC username.
|
||||
|
||||
|
||||
|
||||
This is the user name by which you are identified in Harbor, which is used when adding you to projects, assigning roles, and so on. If the username is already taken, you are prompted to choose another one.
|
||||
1. After the OIDC provider has authenticated you, you are redirected back to Harbor.
|
||||
|
||||
### Using OIDC from the Docker or Helm CLI
|
||||
|
||||
After you have authenticated via OIDC and logged into the Harbor interface for the first time, you can use the Docker or Helm CLI to access Harbor.
|
||||
|
||||
The Docker and Helm CLIs cannot handle redirection for OIDC, so Harbor provides a CLI secret for use when logging in from Docker or Helm. This is only available when Harbor uses OIDC authentication.
|
||||
|
||||
1. Log in to Harbor with an OIDC user account.
|
||||
1. Click your username at the top of the screen and select **User Profile**.
|
||||
|
||||
|
||||
1. Click the clipboard icon to copy the CLI secret associated with your account.
|
||||
|
||||
|
||||
1. Optionally click the **...** icon in your user profile to display buttons for automatically generating or manually creating a new CLI secret.
|
||||
|
||||
|
||||
|
||||
A user can only have one CLI secret, so when a new secret is generated or create, the old one becomes invalid.
|
||||
1. If you generated a new CLI secret, click the clipboard icon to copy it.
|
||||
|
||||
You can now use your CLI secret as the password when logging in to Harbor from the Docker or Helm CLI.
|
||||
|
||||
<pre>
|
||||
docker login -u testuser -p <i>cli_secret</i> jt-test.local.goharbor.io
|
||||
</pre>
|
||||
|
||||
{{< note >}}
|
||||
The CLI secret is associated with the OIDC ID token. Harbor will try to refresh the token, so the CLI secret will be valid after the ID token expires. However, if the OIDC Provider does not provide a refresh token or the refresh fails, the CLI secret becomes invalid. In this case, log out and log back in to Harbor via your OIDC provider so that Harbor can get a new ID token. The CLI secret will then work again.
|
||||
{{< /note >}}
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
---
|
||||
title: Configure Project Quotas
|
||||
weight: 25
|
||||
---
|
||||
|
||||
To exercise control over resource use, as a Harbor system administrator you can set quotas on projects. You can limit the amount of storage capacity that a project can consume. You can set default quotas that apply to all projects globally.
|
||||
|
||||
{{< note >}}
|
||||
Default quotas apply to projects that are created after you set or change the default quota. The default quota is not applied to projects that already existed before you set it.
|
||||
{{< /note >}}
|
||||
|
||||
You can also set quotas on individual projects. If you set a global default quota and you set different quotas on individual projects, the per-project quotas are applied.
|
||||
|
||||
By default, all projects have unlimited quotas for storage use.
|
||||
|
||||
1. Select the **Project Quotas** view.
|
||||
|
||||
|
||||
1. To set global default quotas on all projects, click **Edit**.
|
||||
|
||||
|
||||
|
||||
1. For **Default storage consumption**, enter the maximum quantity of storage that any project can consume, selecting `MB`, `GB`, or `TB` from the drop-down menu, or enter `-1` to set the default to unlimited.
|
||||
|
||||
|
||||
1. Click **OK**.
|
||||
1. To set quotas on an individual project, select the project and then click **Edit**.
|
||||
|
||||
1. For **Default storage consumption**, enter the maximum quantity of storage that this individual project can consume, selecting `MB`, `GB`, or `TB` from the drop-down menu.
|
||||
|
||||
After you set quotas, you can see how much of their quotas each project has consumed.
|
||||
|
||||
|
||||
|
||||
### How Harbor Calculates Resource Usage
|
||||
|
||||
When setting project quotas, it is useful to know how Harbor calculates storage use, especially in relation to image pushing, retagging, and garbage collection.
|
||||
|
||||
- Harbor computes image size when blobs and manifests are pushed from the Docker client.
|
||||
|
||||
{{< note >}}
|
||||
When users push an image, the manifest is pushed last, after all of the associated blobs have been pushed successfully to the registry. If several images are pushed concurrently and if there is an insufficient number of tags left in the quota for all of them, images are accepted in the order that their manifests arrive. Consequently, an attempt to push an image might not be immediately rejected for exceeding the quota. This is because there was availability in the tag quota when the push was initiated, but by the time the manifest arrived the quota had been exhausted.
|
||||
{{< /note >}}
|
||||
- Shared blobs are only computed once per project. In Docker, blob sharing is defined globally. In Harbor, blob sharing is defined at the project level. As a consequence, overall storage usage can be greater than the actual disk capacity.
|
||||
- Retagging images reserves and releases resources:
|
||||
- If you retag an image within a project, the storage usage does not change because there are no new blobs or manifests.
|
||||
- If you retag an image from one project to another, the storage usage will increase.
|
||||
- During garbage collection, Harbor frees the storage used by untagged blobs in the project.
|
||||
- Helm chart size is not calculated.
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
---
|
||||
title: Configuring Replication
|
||||
weight: 30
|
||||
---
|
||||
|
||||
Replication allows users to replicate resources, namely images and charts, between Harbor and non-Harbor registries, in both pull or push mode.
|
||||
|
||||
When the Harbor system administrator has set a replication rule, all resources that match the defined filter patterns are replicated to the destination registry when the triggering condition is met. Each resource that is replicated starts a replication task. If the namespace does not exist in the destination registry, a new namespace is created automatically. If it already exists and the user account that is configured in the replication policy does not have write privileges in it, the process fails. Member information is not replicated.
|
||||
|
||||
There might be some delay during replication based on the condition of the network. If a replication task fails, it is re-scheduled for a few minutes later and retried several times.
|
||||
|
||||
{{< note >}}
|
||||
Due to API changes, replication between different versions of Harbor is not supported.
|
||||
{{< /note >}}
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
---
|
||||
title: Creating Replication Endpoints
|
||||
weight: 20
|
||||
---
|
||||
|
||||
To replicate image repositories from one instance of Harbor to another Harbor or non-Harbor registry, you first create replication endpoints.
|
||||
|
||||
1. Go to **Registries** and click the **+ New Endpoint** button.
|
||||
|
||||
|
||||
|
||||
1. For **Provider**, use the drop-down menu to select the type of registry to set up as a replication endpoint.
|
||||
|
||||
The endpoint can be another Harbor instance, or a non-Harbor registry. Currently, the following non-Harbor registries are supported:
|
||||
|
||||
- Docker Hub
|
||||
- Docker registry
|
||||
- AWS Elastic Container Registry
|
||||
- Azure Container Registry
|
||||
- Ali Cloud Container Registry
|
||||
- Google Container Registry
|
||||
- Huawei SWR
|
||||
- Helm Hub
|
||||
- Gitlab
|
||||
- Quay.io
|
||||
- Jfrog Artifactory
|
||||
|
||||
|
||||
|
||||
1. Enter a suitable name and description for the new replication endpoint.
|
||||
1. Enter the full URL of the registry to set up as a replication endpoint.
|
||||
|
||||
For example, to replicate to another Harbor instance, enter https://harbor_instance_address:443. The registry must exist and be running before you create the endpoint.
|
||||
|
||||
1. Enter the Access ID and Access Secret for the endpoint registry instance.
|
||||
|
||||
Use an account that has the appropriate privileges on that registry, or an account that has write permission on the corresponding project in a Harbor registry.
|
||||
|
||||
{{< note >}}
|
||||
- AWS ECR adapters should use access keys, not a username and password. The access key should have sufficient permissions, such as storage permission.
|
||||
- Google GCR adapters should use the entire JSON key generated in the service account. The namespace should start with the project ID.
|
||||
{{< /note >}}
|
||||
|
||||
1. Optionally, select the **Verify Remote Cert** check box.
|
||||
|
||||
Deselect the check box if the remote registry uses a self-signed or untrusted certificate.
|
||||
|
||||
1. Click **Test Connection**.
|
||||
1. When you have successfully tested the connection, click **OK**.
|
||||
|
||||
## Managing Registries
|
||||
|
||||
You can list, add, edit and delete registries under **Administration** -> **Registries**. Only registries which are not referenced by any rules can be deleted.
|
||||
|
||||
|
||||
|
||||
## What to Do Next
|
||||
|
||||
After you configure replication endpoints, see [Creating a Replication Rule](create-replication-rules.md).
|
||||
|
|
@ -1,67 +0,0 @@
|
|||
---
|
||||
title: Creating a Replication Rule
|
||||
weight: 25
|
||||
---
|
||||
|
||||
A replication endpoint must exist before you create a replication rule. To create an endpoint, follow the instructions in [Creating Replication Endpoints](create-replication-endpoints.md).
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Replications**.
|
||||
|
||||
|
||||
1. Click **New Replication Rule**.
|
||||
1. Provide a name and description for the replication rule.
|
||||
1. Select **Push-based** or **Pull-based** replication, depending on whether you want to replicate artifacts to or from the remote registry.
|
||||
|
||||
|
||||
1. For **Source resource filter**, identify the artifacts to replicate.
|
||||
|
||||
|
||||
|
||||
* **Name**: Replicate resources with a given name by entering an artifact name or fragment.
|
||||
* **Tag**: Replicate resources with a given tag by entering a tag name or fragment.
|
||||
* **Label**: Replicate resources with a given label by using the drop-down menu to select from the available labels.
|
||||
* **Resource**: Replicate artifacts, charts, or both.
|
||||
|
||||
The name filter and tag filters support the following patterns:
|
||||
|
||||
* **\***: Matches any sequence of non-separator characters `/`.
|
||||
* **\*\***: Matches any sequence of characters, including path separators `/`. Note that the doublestar must appear as a path component by itself. A pattern such as /path\*\* is invalid and will be treated the same as /path*, but /path\*/\*\* should achieve the desired result.
|
||||
* **?**: Matches any single non-separator character `/`.
|
||||
* **{alt1,...}**: Matches a sequence of characters if one of the comma-separated alternatives matches.
|
||||
|
||||
**NOTE:** You must add `library` if you want to replicate the official artifacts of Docker Hub. For example, `library/hello-world` matches the official hello-world artifacts.
|
||||
|
||||
Pattern | String(Match or not)
|
||||
---------- | -------
|
||||
`library/*` | `library/hello-world`(Y)<br> `library/my/hello-world`(N)
|
||||
`library/**` | `library/hello-world`(Y)<br> `library/my/hello-world`(Y)
|
||||
`{library,goharbor}/**` | `library/hello-world`(Y)<br> `goharbor/harbor-core`(Y)<br> `google/hello-world`(N)
|
||||
`1.?` | `1.0`(Y)<br> `1.01`(N)
|
||||
1. Use the **Destination Registry** drop-down menu to select from the configured replication endpoints.
|
||||
1. Enter the name of the namespace in which to replicate resources in the **Destination namespace** text box.
|
||||
|
||||
If you do not enter a namespace, resources are placed in the same namespace as in the source registry.
|
||||
|
||||
|
||||
|
||||
**NOTE:** Because of major API changes in the v2.0 release to support [OCI](https://github.com/opencontainers/distribution-spec).
|
||||
You **can not** replicate from harbor 1.x to 2.0, and you **can not** replicate artifacts with **manifest list** from 2.0 to 1.x.
|
||||
|
||||
1. Use the Trigger Mode drop-down menu to select how and when to run the rule.
|
||||
* **Manual**: Replicate the resources manually when needed. **Note**: Deletion operations are not replicated.
|
||||
* **Scheduled**: Replicate the resources periodically by defining a cron job. **Note**: Deletion operations are not replicated.
|
||||
* **Event Based**: When a new resource is pushed to the project, or an artifact is retagged, it is replicated to the remote registry immediately. If you select the **Delete remote resources when locally deleted**, if you delete an artifact, it is automatically deleted from the replication target.
|
||||
|
||||
{{< note >}}
|
||||
You can filter artifacts for replication based on the labels that are applied to the artifacts. However, changing a label on an artifact does not trigger replication. Event-based replication is limited to pushing, retagging, and deleting artifacts.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
1. Optionally select the Override checkbox to force replicated resources to replace resources at the destination with the same name.
|
||||
1. Click **Save** to create the replication rule.
|
||||
|
||||
## What to Do Next
|
||||
|
||||
After you create a replication rule, see [Running Replication Manually](manage-replications.md).
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
---
|
||||
title: Running Replication Manually
|
||||
weight: 30
|
||||
---
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Replications**.
|
||||
1. Select a replication rule and click **Replicate**.
|
||||
|
||||
|
||||
|
||||
The resources to which the rule is applied start to replicate from the source registry to the destination immediately.
|
||||
1. Click the rule to see its execution status.
|
||||
1. Click the **ID** of the execution to see the details of the replication and the task list. The count of `IN PROGRESS` status in the summary includes both `Pending` and `In Progress` tasks.
|
||||
1. Optionally click **STOP** to stop the replication.
|
||||
1. Click the log icon to see detailed information about the replication task.
|
||||
|
||||
|
||||
|
||||
To edit or delete a replication rule, select the replication rule in the **Replications** view and click **Edit** or **Delete**. Only rules which have no executions in progress can be edited deleted.
|
||||
|
||||
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
---
|
||||
title: Garbage Collection
|
||||
weight: 40
|
||||
---
|
||||
|
||||
When you delete images from Harbor, space is not automatically freed up. You must run garbage collection to free up space by removing blobs that are no longer referenced by a manifest from the file system.
|
||||
|
||||
## Run Garbage Collection
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Garbage Collection**.
|
||||
1. Select the **'Garbage Collection'** tab.
|
||||
|
||||
|
||||
|
||||
1. To delete untagged artifacts, select the check box **Delete Untagged Artifacts**.
|
||||
1. To run garbage collection immediately, click **GC Now**.
|
||||
|
||||
When you run garbage collection, Harbor goes into read-only mode. All modifications to the registry are prohibited.
|
||||
|
||||
To avoid triggering the garbage collection process too frequently, the availability of the **GC Now** button is restricted. Garbage collection can be only run once per minute.
|
||||
|
||||
## Schedule Garbage Collection
|
||||
|
||||
1. Expand **Administration**, and select **Garbage Collection**.
|
||||
1. Select the **'Garbage Collection'** tab.
|
||||
1. Use the drop down-menu to select how often to run garbage collection.
|
||||
|
||||
|
||||
|
||||
* **None**: No garbage collection is scheduled.
|
||||
* **Hourly**: Run garbage collection at the beginning of every hour.
|
||||
* **Daily**: Run garbage collection at midnight every day.
|
||||
* **Weekly**: Run garbage collection at midnight every Saturday.
|
||||
* **Custom**: Run garbage collection according to a `cron` job.
|
||||
|
||||
1. To delete untagged artifacts, select the check box **Delete Untagged Artifacts**.
|
||||
1. Click **Save**.
|
||||
1. Select the **History** tab to view records of the 10 most recent garbage collection runs.
|
||||
|
||||
|
||||
|
||||
1. Click on the **Logs** link to view the related logs.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
title: Configure Global Settings
|
||||
weight: 20
|
||||
---
|
||||
|
||||
You can configure Harbor to connect to an email server, set the registry in read-only mode, and configure Harbor so that only system administrators can create projects.
|
||||
|
||||
## Configure an Email Server
|
||||
|
||||
You can configure Harbor to connect to an email server. The email server is only used to send out responses to users who request to reset their password.
|
||||
|
||||
|
||||
|
||||
## Make the Registry Read Only
|
||||
|
||||
You can set Harbor to read-only mode. In read-only mode, Harbor allows `docker pull` but prevents `docker push` and the deletion of repositories and tags.
|
||||
|
||||
|
||||
|
||||
If it set to true, deleting repositories, tags and pushing images are not permitted.
|
||||
|
||||
|
||||
|
||||
```sh
|
||||
docker push 10.117.169.182/demo/ubuntu:14.04
|
||||
The push refers to a repository [10.117.169.182/demo/ubuntu]
|
||||
0271b8eebde3: Preparing
|
||||
denied: The system is in read only mode. Any modification is prohibited.
|
||||
```
|
||||
|
||||
## Set Who Can Create Projects
|
||||
|
||||
Use the **Project Creation** drop-down menu to set which users can create projects. Select **Everyone** to allow all users to create projects. Select **Admin Only** to allow only users with the Harbor system administrator role to create projects.
|
||||
|
||||
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
---
|
||||
title: Managing Users
|
||||
weight: 15
|
||||
---
|
||||
|
||||
Harbor manages images through projects. You provide access to these images to users by including the users in projects and assigning one of the following roles to them.
|
||||
|
||||
|
||||
|
||||
* **Limited Guest**: A Limited Guest does not have full read privileges for a project. They can pull images but cannot push, and they cannot see logs or the other members of a project. For example, you can create limited guests for users from different organizations who share access to a project.
|
||||
* **Guest**: Guest has read-only privilege for a specified project. They can pull and retag images, but cannot push.
|
||||
* **Developer**: Developer has read and write privileges for a project.
|
||||
* **Master**: Master has elevated permissions beyond those of 'Developer' including the ability to scan images, view replications jobs, and delete images and helm charts.
|
||||
* **ProjectAdmin**: When creating a new project, you will be assigned the "ProjectAdmin" role to the project. Besides read-write privileges, the "ProjectAdmin" also has some management privileges, such as adding and removing members, starting a vulnerability scan.
|
||||
|
||||
Besides the above roles, there are two system-level roles:
|
||||
|
||||
* **Harbor system administrator**: "Harbor system administrator" has the most privileges. In addition to the privileges mentioned above, "Harbor system administrator" can also list all projects, set an ordinary user as administrator, delete users and set vulnerability scan policy for all images. The public project "library" is also owned by the administrator.
|
||||
* **Anonymous**: When a user is not logged in, the user is considered as an "Anonymous" user. An anonymous user has no access to private projects and has read-only access to public projects.
|
||||
|
||||
For full details of the permissions of the different roles, see [User Permissions By Role](user-permissions-by-role.md).
|
||||
|
||||
If you run Harbor in database authentication mode, you create user accounts directly in the Harbor interface. For information about how to create local user accounts, see [Create User Accounts in Database Mode](create-users-db.md).
|
||||
|
||||
If you run Harbor in LDAP/AD or OIDC authentication mode, you create and manage user accounts in your LDAP/AD or OIDC provider. Harbor obtains the users from the LDAP/AD or OIDC server and displays them in the **Users** tab of the Harbor interface.
|
||||
|
||||
## Assigning the Harbor System Administrator Role
|
||||
|
||||
Harbor system administrators can assign the Harbor system administrator role to other users by selecting usernames and clicking **Set as Administrator** in the **Users** tab.
|
||||
|
||||
|
||||
|
||||
To delete users, select a user and click `DELETE`. Deleting users is only supported under database authentication mode.
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
---
|
||||
title: Create User Accounts in Database Mode
|
||||
weight: 25
|
||||
---
|
||||
|
||||
In database authentication mode, the Harbor system administrator creates user accounts manually.
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Under **Administration**, go to **Users**.
|
||||
|
||||
|
||||
1. Click **New User**.
|
||||
1. Enter information about the new user.
|
||||
|
||||
|
||||
|
||||
- The username must be unique in the Harbor system
|
||||
- The email address is used for password recovery
|
||||
- The password must contain at least 8 characters with 1 lowercase letter, 1 uppercase letter and 1 numeric character
|
||||
|
||||
If users forget their password, there is a **Forgot Password** in the Harbor log in page. To use this feature, you must [configure an email server](../general-settings/_index.md).
|
||||
|
|
@ -1,63 +0,0 @@
|
|||
---
|
||||
title: User Permissions By Role
|
||||
weight: 20
|
||||
---
|
||||
|
||||
Users have different abilities depending on the role they in a project.
|
||||
|
||||
On public projects all users will be able to see the list of repositories, images, image vulnerabilities, helm charts and helm chart versions, pull images, retag images (need push permission for destination image), download helm charts, download helm chart versions.
|
||||
|
||||
System admin have all permissions for the project.
|
||||
|
||||
## Project members permissions
|
||||
|
||||
The following table depicts the various user permission levels in a project.
|
||||
|
||||
| Action | Limited Guest | Guest | Developer | Master | Project Admin |
|
||||
| --------------------------------------- | ------------- | ----- | --------- | ------ | ------------- |
|
||||
| See the project configurations | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Edit the project configurations | | | | | ✓ |
|
||||
| See a list of project members | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Create/edit/delete project members | | | | | ✓ |
|
||||
| See a list of project logs | | ✓ | ✓ | ✓ | ✓ |
|
||||
| See a list of project replications | | | | ✓ | ✓ |
|
||||
| See a list of project replication jobs | | | | | ✓ |
|
||||
| See a list of project labels | | | | ✓ | ✓ |
|
||||
| Create/edit/delete project labels | | | | ✓ | ✓ |
|
||||
| See a list of repositories | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Create repositories | | | ✓ | ✓ | ✓ |
|
||||
| Edit/delete repositories | | | | ✓ | ✓ |
|
||||
| See a list of images | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Retag image | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Pull image | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Push image | | | ✓ | ✓ | ✓ |
|
||||
| Scan/delete image | | | | ✓ | ✓ |
|
||||
| Add scanners to Harbor | | | | | |
|
||||
| Edit scanners in projects | | | | | ✓ |
|
||||
| See a list of image vulnerabilities | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| See image build history | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Add/Remove labels of image | | | ✓ | ✓ | ✓ |
|
||||
| See a list of helm charts | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Download helm charts | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Upload helm charts | | | ✓ | ✓ | ✓ |
|
||||
| Delete helm charts | | | | ✓ | ✓ |
|
||||
| See a list of helm chart versions | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Download helm chart versions | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Upload helm chart versions | | | ✓ | ✓ | ✓ |
|
||||
| Delete helm chart versions | | | | ✓ | ✓ |
|
||||
| Add/Remove labels of helm chart version | | | ✓ | ✓ | ✓ |
|
||||
| See a list of project robots | | | | ✓ | ✓ |
|
||||
| Create/edit/delete project robots | | | | | ✓ |
|
||||
| See configured CVE allowlist | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Create/edit/remove CVE allowlist | | | | | ✓ |
|
||||
| View webhook events | | | | ✓ | ✓ |
|
||||
| Add new webhook events | | | | | ✓ |
|
||||
| Enable/disable webhooks | | | | | ✓ |
|
||||
| Create/delete tag retention rules | | | ✓ | ✓ | ✓ |
|
||||
| Enable/disable tag retention rules | | | ✓ | ✓ | ✓ |
|
||||
| Create/delete tag immutability rules | | | | | ✓ |
|
||||
| Enable/disable tag immutability rules | | | | | ✓ |
|
||||
| See project quotas | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Edit project quotas * | | | | | |
|
||||
|
||||
* Only the Harbor system administrator can edit project quotas and add new scanners.
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
---
|
||||
title: Upgrade Harbor and Migrate Data
|
||||
weight: 45
|
||||
---
|
||||
|
||||
This guide covers upgrade and migration to version 2.0.0. This guide only covers migration from v1.9.x and later to the current version. If you are upgrading from an earlier version, refer to the migration guide in the `release-1.9.0` branch to upgrade to v1.9.x first, then follow this guide to perform the migration to this version.
|
||||
|
||||
If you are upgrading a Harbor instance that you deployed with Helm, see [Upgrading Harbor Deployed with Helm](helm-upgrade.md).
|
||||
|
||||
When upgrading an existing Harbor instance to a newer version, you might need to migrate the settings in `harbor.yml`.
|
||||
Since the migration might alter the database schema and the settings of `harbor.yml`, you should **always** back up your data before any migration.
|
||||
|
||||
## Notes
|
||||
|
||||
- Again, you must back up your data before any data migration.
|
||||
- In version 1.9.0, some containers are started by `non-root`. This does not pose problems if you are upgrading an officially released version of Harbor, but if you have deployed a customized instance of Harbor, you might encounter permission issues.
|
||||
- In previous releases, user roles took precedence over group roles in a project. In this version, user roles and group roles are combined so that the user has whichever set of permissions is highest. This might cause the roles of certain users to change during upgrade.
|
||||
- With the introduction of storage and artifact quotas in version 1.9.0, migration from 1.8.x might take a few minutes. This is because the `core` walks through all blobs in the registry and populates the database with information about the layers and artifacts in projects.
|
||||
- With the introduction of storage and artifact quotas in version 1.9.0, replication between version 1.9.0 and a previous version of Harbor does not work. You must upgrade all Harbor nodes to 1.9.0 if you have configured replication between them.
|
||||
|
||||
## Upgrading Harbor and Migrating Data
|
||||
|
||||
1. Log in to the Harbor host and, if it is still running, stop and remove the existing Harbor instance.
|
||||
|
||||
```sh
|
||||
cd harbor
|
||||
docker-compose down
|
||||
```
|
||||
|
||||
1. Back up Harbor's current files so that you can roll back to the current version if necessary.
|
||||
|
||||
```sh
|
||||
mv harbor /my_backup_dir/harbor
|
||||
```
|
||||
|
||||
1. Back up the database, which by default is in the directory `/data/database`.
|
||||
|
||||
```sh
|
||||
cp -r /data/database /my_backup_dir/
|
||||
```
|
||||
|
||||
1. Get the latest Harbor release package from [https://github.com/goharbor/harbor/releases](https://github.com/goharbor/harbor/releases).
|
||||
1. Before upgrading Harbor, perform migration.
|
||||
|
||||
The migration tool is in harbor-prepare tools delivered as a docker image. You can pull the image from docker hub. in the following command:
|
||||
|
||||
```sh
|
||||
docker pull goharbor/prepare:[tag]
|
||||
```
|
||||
|
||||
Alternatively, if you are using an offline installer package, you can load it from the image tarball that is included in the offline installer package. Replace [tag] with the new Harbor version, for example v1.10.0, in the following command:
|
||||
|
||||
```sh
|
||||
tar zxf <offline package>
|
||||
docker image load -i harbor/harbor.[version].tar.gz
|
||||
```
|
||||
|
||||
1. Copy the `harbor.yml.tmp` to `harbor.yml` and upgrade it.
|
||||
|
||||
```sh
|
||||
docker run -it --rm -v /:/hostfs goharbor/prepare:[tag] migrate -i ${path to harbor.yml}
|
||||
```
|
||||
|
||||
**NOTE:** The schema upgrade and data migration of the database is performed by core when Harbor starts. If the migration fails, check the core log to debug.
|
||||
|
||||
3. In the `./harbor` directory, run the `./install.sh` script to install the new Harbor instance.
|
||||
|
||||
To install Harbor with components such as Notary, Clair, and chartmuseum, see [Run the Installer Script](../../install-config/run-installer-script.md) for more information.
|
||||
|
||||
If you need to roll back to the previous version of Harbor, see [Roll Back from an Upgrade](roll-back-upgrade.md).
|
||||
|
|
@ -1,68 +0,0 @@
|
|||
---
|
||||
title: Upgrading Harbor Deployed with Helm
|
||||
weight: 40
|
||||
---
|
||||
|
||||
This guide is used to upgrade Harbor deployed by chart since version 0.3.0.
|
||||
|
||||
## Notes
|
||||
|
||||
- As the database schema may change between different versions of Harbor, there is a progress to migrate the schema during the upgrade and the downtime cannot be avoid
|
||||
- The database schema cannot be downgraded automatically, so the `helm rollback` is not supported
|
||||
|
||||
## Upgrade
|
||||
|
||||
### 1. Backup database
|
||||
|
||||
Backup the database used by Harbor in case the upgrade process fails.
|
||||
|
||||
### 2. Download new chart
|
||||
|
||||
Download the latest version of Harbor chart.
|
||||
|
||||
### 3. Configure new chart
|
||||
|
||||
Configure the new chart to make sure that the configuration items have the same values with the old one.
|
||||
|
||||
> Note: if TLS is enabled and the certificate is generated by chart automatically, a new certificate will be generated and overwrite the old one during the upgrade, this may cause some issues if you have distributed the certificate. You can follow the below steps to configure the new chart to use the old certificate:
|
||||
|
||||
1. Get the secret name which certificate is stored in:
|
||||
|
||||
```bash
|
||||
kubectl get secret
|
||||
```
|
||||
|
||||
Find the secret whose name ends with `-harbor-ingress` (expose service via `Ingress`) or `-harbor-nginx`(expose service via `ClusterIP` or `NodePort`)
|
||||
|
||||
2. Export the secret as yaml file:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl get secret <secret-name-from-step-1> -o yaml > secret.yaml
|
||||
```
|
||||
|
||||
3. Rename the secret by setting `metadata.name` in `secret.yaml`
|
||||
|
||||
4. Create a new secret:
|
||||
|
||||
```bash
|
||||
kubectl create -f secret.yaml
|
||||
```
|
||||
|
||||
5. Configure the chart to use the new secret by setting `expose.tls.secretName` as the value you set in step **3**
|
||||
|
||||
### 4. Upgrade
|
||||
|
||||
Run upgrade command:
|
||||
|
||||
```bash
|
||||
helm upgrade release-name --force .
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
The `--force` is necessary if upgrade from version 0.3.0 due to issue [#30](https://github.com/goharbor/harbor-helm/issues/30).
|
||||
{{< /note >}}
|
||||
|
||||
## Known issues
|
||||
|
||||
- The job logs will be lost if you upgrade from version 0.3.0 as the logs are store in a `emptyDir` in 0.3.0.
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
---
|
||||
title: Roll Back from an Upgrade
|
||||
weight: 45
|
||||
---
|
||||
|
||||
If, for any reason, you need to roll back to the previous version of Harbor, perform the following steps.
|
||||
|
||||
{{< note >}}
|
||||
To roll back from an upgrade, you must have backed up the previous version of Harbor. For information about backing up Harbor before an upgrade, see [Upgrade Harbor and Migrate Data](_index.md).
|
||||
{{< /note >}}
|
||||
|
||||
1. Stop and remove the current Harbor service if it is still running.
|
||||
|
||||
```sh
|
||||
cd harbor
|
||||
docker-compose down
|
||||
```
|
||||
|
||||
2. Remove current Harbor instance.
|
||||
|
||||
```sh
|
||||
rm -rf harbor
|
||||
```
|
||||
|
||||
3. Restore the older version of Harbor.
|
||||
|
||||
```sh
|
||||
mv /my_backup_dir/harbor harbor
|
||||
```
|
||||
|
||||
4. To restore the database, copy the data files from the backup directory to your data volume, which by default is `/data/database`.
|
||||
|
||||
5. Restart the Harbor service using the previous configuration.
|
||||
|
||||
If the previous version of Harbor was installed by a release build:
|
||||
|
||||
```sh
|
||||
cd harbor
|
||||
./install.sh
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
While you can roll back an upgrade to the state before you started the upgrade, Harbor does not support downgrades.
|
||||
{{< /note >}}
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
---
|
||||
title: Test Harbor Upgrade
|
||||
weight: 50
|
||||
---
|
||||
|
||||
## Prepare data
|
||||
1. Add user usera userb userc userd usere, set usera userb as system admin.
|
||||
2. Create project projecta projectc as private, create projectb as public.
|
||||
3. Add usera as projecta's admin, userc as developer, and userd as guest. Do the same to projectb and projectc.
|
||||
4. Login harbor as usera, push an unsigned image into projecta, then push a signed image to projecta.
|
||||
5. Login harbor as userc, push an unsigned image into projecta, then push a signed image to projeca.
|
||||
6. Login harbor as userd, push each image one time.
|
||||
7. Repeat 4 5 6 to projectb and projectc.
|
||||
8. Add one endpoint to harbor.
|
||||
9. Add an immediate replication rule to projeca, a schedule rule to projectb, a manual rule to projectc, trigger each rule one time.
|
||||
10. Add 5 system label syslabel1 to syslabel5 and tag syslabel1 and syslabel2 to all unsigned image.
|
||||
11. In each project add 5 project label projlabela to projlabele, add projlabela projlabelb and projlabelc to signed image.
|
||||
12. Trigger one scan all job to scan all images.(For clair enabled instance)
|
||||
13. Update project publicly, content trust, severity and scanning settings.
|
||||
14. Update Harbor email, token expire read only and scan settings.
|
||||
15. Update repository info.
|
||||
**NOTE**: Create user step is not needed if auth mode is LDAP.
|
||||
|
||||
# Upgrade
|
||||
|
||||
## Follow the upgrade guide
|
||||
1. Run db migrator image to backup database.
|
||||
2. Run db migrator image to migrate database.
|
||||
3. Install new version harbor.
|
||||
|
||||
# After upgrade
|
||||
|
||||
1. Confirm users are exist and available(No need for VIC and LDAP Mode).
|
||||
2. Confirm users have the correct role.
|
||||
3. Confirm labels are existing and labeled correct.(No need for VIC)
|
||||
4. Confirm notary signature correct.
|
||||
5. Confirm endpoint exist.
|
||||
6. Confirm replication rule exist and works well.
|
||||
7. Confirm project level settings(publicly, content trust, scan) same as before.
|
||||
8. Confirm system level settings(email token expire scan) same as before.
|
||||
9. Confirm scan result the same as before upgrade.
|
||||
10. Confirm access log the same as before upgrade.
|
||||
11. Confirm repository info the same as before.
|
||||
12. Confirm other image metadata(e.g. author, size) the same as before.
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
---
|
||||
title: Vulnerability Scanning
|
||||
weight: 35
|
||||
---
|
||||
|
||||
Harbor provides static analysis of vulnerabilities in images through the open source projects [Trivy](https://github.com/aquasecurity/trivy) and [Clair](https://github.com/coreos/clair). To be able to use Trivy, Clair or both you must have enabled Trivy, Clair or both when you installed your Harbor instance (by appending installation options `--with-trivy`, `--with-clair` or both).
|
||||
|
||||
{{< important >}}
|
||||
Currently, Harbor supports only one system default scanner. The following principles will be applied to determine the system default scanner among the default installed scanners.
|
||||
|
||||
For a brand new installation:
|
||||
|
||||
If no scanner is installed, no system default scanner will be set then;
|
||||
|
||||
If only one scanner (either Trivy or Clair) is installed, the installed one will become the system default scanner automatically;
|
||||
|
||||
If both Trivy and Clair are installed, Trivy will be the system default scanner then.
|
||||
|
||||
For upgrades:
|
||||
|
||||
If the upgrading path is from the version that is >=V1.10 to current version (V2.0) and there was an existing system default scanner “ABC” is set in the previous version, that scanner "ABC" will be kept as system default scanner;
|
||||
|
||||
Otherwise, Harbor will do the similar operation to the above brand new installation case.
|
||||
{{< /important >}}
|
||||
|
||||
You can also connect Harbor to your own instance of Trivy/Clair or to other additional vulnerability scanners through Harbor's embedded interrogation service. These scanners can be configured in the Harbor UI at any time after installation. For the list of additional scanners that are currently supported, see the [Harbor Compatibility List](../../install-config/harbor-compatibility-list.md#scanner-adapters).
|
||||
|
||||
It might be necessary to connect Harbor to other scanners for corporate compliance reasons, or because your organization already uses a particular scanner. Different scanners also use different vulnerability databases, capture different CVE sets, and apply different severity thresholds. By connecting Harbor to more than one vulnerability scanner, you broaden the scope of your protection against vulnerabilities.
|
||||
|
||||
For information about installing Harbor with Clair, see the [Run the Installer Script](../../install-config/run-installer-script.md).
|
||||
|
||||
You can manually initiate scanning on a particular image, or on all images in Harbor. Additionally, you can also set a policy to automatically scan all of the images at specific intervals.
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
---
|
||||
title: Configure System-Wide CVE Allowlists
|
||||
weight: 50
|
||||
---
|
||||
|
||||
When you run vulnerability scans, images that are subject to Common Vulnerabilities and Exposures (CVE) are identified. According to the severity of the CVE and your security settings, these images might not be permitted to run. As a Harbor system administrator, you can create allowlists of CVEs to ignore during vulnerability scanning.
|
||||
|
||||
You can set a system-wide CVE allowlist or you can set CVE allowlists on a per-project basis. For information about per-project CVE allowlists, see [Configure a Per-Project CVE Allowlist](../../working-with-projects/project-configuration/configure-project-allowlist.md).
|
||||
|
||||
System-wide CVE allowlists apply to all of the projects in a Harbor instance.
|
||||
|
||||
1. Go to **Configuration** > **System Settings**.
|
||||
1. Under **Deployment security**, click **Add**.
|
||||
|
||||
1. Enter the list of CVE IDs to ignore during vulnerability scanning.
|
||||
|
||||
|
||||
Either use a comma-separated list or newlines to add multiple CVE IDs to the list.
|
||||
1. Click **Add** at the bottom of the window to add the list.
|
||||
1. Optionally uncheck the **Never expires** checkbox and use the calendar selector to set an expiry date for the allowlist.
|
||||
|
||||
1. Click **Save** at the bottom of the page to save your settings.
|
||||
|
||||
After you have created a system allowlist, you can remove CVE IDs from the list by clicking the delete button next to it in the list. You can click **Add** to add more CVE IDs to the system allowlist.
|
||||
|
||||
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
---
|
||||
title: Deployment security
|
||||
weight: 31
|
||||
---
|
||||
|
||||
Starting in version 2.0, Harbor has added capabilities to check for supported artifact types in the pluggable scanners. It will use the **consumes_mime_types** metadata of the scanner to decide whether a requested artifact is supported by this scanner. For example, helm charts cannot be scanned for vulnerabilities by any of the supported scanners like Clair or Aqua Trivy.
|
||||
|
||||
Harbor v2.0 now supports OCI image index, which is a higher-level manifest which points to specific image manifests, ideal for one or more platform. Scanning for OCI image index is also supported, with the scan result of the index being an aggregation of the scan results of the artifacts referenced within.
|
||||
|
||||
Harbor has ‘deployment security’ which can prevent artifacts from being pulled if vulnerabilities are discovered. For pulling indexes, ‘deployment security’ will skip this policy checking for the index artifact itself and will only apply policy checking on the referenced artifacts and at the individual artifact level and not on the index as a whole. This means when pulling Redis for ARM for example, it only checks to see if whether Redis for ARM has vulnerabilities and not impacted by whether amd64 has CVEs. This applies to CNABs as well.
|
||||
|
|
@ -1,65 +0,0 @@
|
|||
---
|
||||
title: Import Vulnerability Data to an Offline Harbor instance
|
||||
weight: 45
|
||||
---
|
||||
|
||||
If Harbor is installed in an environment without an internet connection, Clair cannot fetch data from the public vulnerability database. In this case, the Harbor administrator must update the Clair database manually.
|
||||
|
||||
## Preparation
|
||||
|
||||
- You have an instance of Clair that has an internet connection. If you have another instance of Harbor that has internet access, this also works.
|
||||
- Check whether your Clair instance has already updated its vulnerability database to the latest version.
|
||||
|
||||
1. Use `docker ps` to find out the container ID of the Clair service.
|
||||
1. Run `docker logs <container_id>` to check the log of the Clair container. If you are using Harbor you can find the latest Clair logs under `/var/log/harbor/2017-xx-xx/clair.log`.
|
||||
1. Look for logs that look like the following:
|
||||
|
||||
```
|
||||
Jul 3 20:40:45 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 03:40:45.890364","updater name":"rhel"}
|
||||
Jul 3 20:40:46 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 03:40:46.768924","updater name":"alpine"}
|
||||
Jul 3 20:40:47 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 03:40:47.190982","updater name":"oracle"}
|
||||
Jul 3 20:41:07 172.18.0.1 clair[3516]: {"Event":"Debian buster is not mapped to any version number (eg. Jessie-\u003e8). Please update me.","Level":"warning","Location":"debian.go:128","Time":"2017-07-04 03:41:07.833720"}
|
||||
Jul 3 20:41:07 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 03:41:07.833975","updater name":"debian"}
|
||||
Jul 4 00:26:17 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 07:26:17.596986","updater name":"ubuntu"}
|
||||
Jul 4 00:26:18 172.18.0.1 clair[3516]: {"Event":"adding metadata to vulnerabilities","Level":"info","Location":"updater.go:253","Time":"2017-07-04 07:26:18.060810"}
|
||||
Jul 4 00:38:05 172.18.0.1 clair[3516]: {"Event":"update finished","Level":"info","Location":"updater.go:198","Time":"2017-07-04 07:38:05.251580"}
|
||||
```
|
||||
The phrase `finished fetching` indicates that Clair has finished a round of vulnerability updates from an endpoint. Make sure all of the `rhel`, `alpine`, `oracle`, `debian`, and `ubuntu` endpoints are updated correctly. If they have not, wait for Clair to get the data.
|
||||
|
||||
## Dump Vulnerability Data
|
||||
|
||||
1. Log in to the host, that is connected to Internet, on which the Postgres Clair database is running.
|
||||
1. Dump Clair's vulnerability database by running the following commands.
|
||||
|
||||
{{< note >}}
|
||||
The container name `clair-db` is a placeholder for the database container used by the internet-connected instance of Clair.
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
$ docker exec clair-db /bin/sh -c "pg_dump -U postgres -a -t feature -t keyvalue -t namespace -t schema_migrations -t vulnerability -t vulnerability_fixedin_feature" > vulnerability.sql
|
||||
$ docker exec clair-db /bin/sh -c "pg_dump -U postgres -c -s" > clear.sql
|
||||
```
|
||||
|
||||
The files `vulnerability.sql` and `clear.sql` are generated.
|
||||
|
||||
## Back Up the Harbor Clair Database
|
||||
|
||||
Before importing the data, it is strongly recommended to back up the Clair database in Harbor.
|
||||
|
||||
```shell
|
||||
docker exec harbor-db /bin/sh -c "pg_dump -U postgres -c" > all.sql
|
||||
```
|
||||
|
||||
## Update the Harbor Clair Database
|
||||
|
||||
1. Copy the `vulnerability.sql` and `clear.sql` files to the host on which Harbor is running.
|
||||
1. Run the following commands to import the data to the Harbor Clair database:
|
||||
|
||||
```shell
|
||||
docker exec -i harbor-db psql -U postgres < clear.sql
|
||||
docker exec -i harbor-db psql -U postgres < vulnerability.sql
|
||||
```
|
||||
|
||||
## Rescan the Images
|
||||
|
||||
After importing the data, trigger the scanning process in the Harbor interface. For information about running a scan, see [Scan All Images](scan-all-images.md).
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
---
|
||||
title: Connect Harbor to Additional Vulnerability Scanners
|
||||
weight: 25
|
||||
---
|
||||
|
||||
To connect Harbor to additional vulnerability scanners, you must install and configure an instance of the additional scanner according to the scanner vendor's requirements. The scanner must expose an API endpoint to allow Harbor to trigger the scan process or get reports. You can deploy multiple different scanners, and multiple instances of the same type of scanner.
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Interrogation Services**.
|
||||
|
||||
1. Click the **New Scanner** button.
|
||||
1. Enter the information to identify the scanner.
|
||||
- A unique name for this scanner instance, to display in the Harbor interface.
|
||||
- An optional description of this scanner instance.
|
||||
- The address of the API endpoint that the scanner exposes to Harbor.
|
||||
|
||||
1. Select how to connect to the scanner from the **Authorization** drop-down menu.
|
||||
|
||||
- **None**: The scanner allows all connections without any security.
|
||||
- **Basic**: Enter a username and password for an account that can connect to the scanner.
|
||||
- **Bearer**: Paste the contents of a bearer token in the **Token** text box.
|
||||
- **APIKey**: Paste the contents of an API key for the scanner in the **APIKey** text box.
|
||||
1. Optionally select **Skip certificate verification** if the scanner uses a self-signed or untrusted certificate.
|
||||
1. Optionally select **Use internal registry address** if the scanner should connect to Harbor using an internal network address rather than its external URL.
|
||||
|
||||
**NOTE**: To use this option, the scanner must be deployed in a network that allows the scanner to reach Harbor via Harbor's internal network.
|
||||
1. Click **Test Connection** to make sure that Harbor can connect successfully to the scanner.
|
||||
|
||||
1. Click **Add** to connect Harbor to the scanner.
|
||||
1. Optionally repeat the procedure to add more scanners.
|
||||
1. If you configure multiple scanners, select one and click **Set as Default** to designate it as the default scanner.
|
||||
|
||||
## Vulnerability Metadata
|
||||
|
||||
Vulnerability scanners depend on the vulnerability metadata to complete the analysis process. After the first initial installation, the vulnerability scanner automatically starts to update the metadata database from different vulnerability repositories. The database update might take a while, based on the data size and network connection.
|
||||
|
||||
Depending on the scanner that you use, once the database is ready, the timestamp of the last update is shown in the **Interrogation Services** > **Vulnerability** tab. Currently, only Clair and Anchore provide timestamp information.
|
||||
|
||||
|
||||
Until the database has been fully populated, the timestamp is replaced by a warning symbol. When the database is ready, you can scan images individually or scan all images across all projects.
|
||||
|
||||
If your Harbor instance is not connected to the external internet, you must manually update the vulnerability metadata. For information about how to update Clair manually, see [Import Vulnerability Data to an Offline Harbor instance](import-vulnerability-data.md).
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
---
|
||||
title: Scan All Artifacts
|
||||
weight: 35
|
||||
---
|
||||
|
||||
In addition to scanning individual artifacts in projects, you can run global scans on all of the artifacts in a Harbor instance, across all projects.
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Interrogation Services**.
|
||||
1. Select the **Vulnerability** tab and click **Scan Now** to scan all of the artifacts in all projects.
|
||||
|
||||
|
||||
|
||||
Scanning requires intensive resource consumption. If scanning is in progress, the **Scan Now** button is unavailable.
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
---
|
||||
title: Scan Individual Artifacts
|
||||
weight: 30
|
||||
---
|
||||
|
||||
1. Log in to the Harbor interface with an account that has at least project administrator privileges.
|
||||
1. Go to **Projects** and select a project.
|
||||
1. Select the **Scanner** tab.
|
||||
|
||||
The **Scanner** tab shows the details of the scanner that is currently set as the scanner to use for this project.
|
||||
|
||||
|
||||
|
||||
1. Click **Edit** to select a different scanner from the list of scanners that are connected to this Harbor instance, and click **OK**.
|
||||
|
||||
|
||||
|
||||
{{< note >}}
|
||||
If you have selected the **Prevent vulnerable images from running** option in the project **Configuration** tab, the prevention of pulling vulnerable artifacts is determined by the scanner that is set in the project, or by the global default scanner if no scanner is configured specifically for the project. Different scanners might apply different levels of severity to artifact vulnerabilities.
|
||||
{{< /note >}}
|
||||
|
||||
1. Select the **Repositories** tab and select a repository.
|
||||
|
||||
For each artifact in the repository, the **Vulnerabilities** column displays the vulnerability scanning status and related information.
|
||||
|
||||
|
||||
|
||||
1. Select a artifact, or use the check box at the top to select all artifacts in the repository, and click the **Scan** button to run the vulnerability scan on this artifact.
|
||||
|
||||
|
||||
|
||||
**NOTE**: You can start a scan at any time, unless the status is **Queued** or **Scanning**. If the database has not been fully populated, you should not run a scan. The following statuses are displayed in the **Vulnerabilities** column:
|
||||
|
||||
* **Not Scanned:** The artifact has never been scanned.
|
||||
* **Unsupported:** The artifact is not supported by the scanner.
|
||||
* **Queued:** The scanning task is scheduled but has not run yet.
|
||||
* **Scanning:** The scanning task is in progress and a progress bar is displayed.
|
||||
* **View log:** The scanning task failed to complete. Click **View Log** link to view the related logs.
|
||||
* **Complete:** The scanning task completed successfully.
|
||||
|
||||
If the process completes successfully, the result indicates the overall severity level, with the total number of vulnerabilities found for each severity level, and the number of fixable vulnerabilities.
|
||||
|
||||
|
||||
|
||||
* **Red:** At least one critical vulnerability found
|
||||
* **Orange:** At least one high level vulnerability found
|
||||
* **Yellow:** At least one medium level vulnerability found
|
||||
* **Blue:** At least one low level vulnerability found
|
||||
* **Green:** No vulnerabilities found
|
||||
* **Grey:** Unknown vulnerabilities
|
||||
|
||||
1. Hover over the number of fixable vulnerabilities to see a summary of the vulnerability report.
|
||||
|
||||
|
||||
|
||||
1. Click on the artifact digest to see a detailed vulnerability report.
|
||||
|
||||
|
||||
|
||||
In addition to information about the artifact, all of the vulnerabilities found in the last scan are listed. You can order or filter the list by the different columns. You can also click **Scan** in the report page to run a scan on this artifact.
|
||||
|
||||
|
||||
## Vulnerability scanning for OCI image index
|
||||
|
||||
When scanning an OCI image index, Harbor will send scan requests for each of the referenced artifact which is supported by the scanner to the scanner. If the image scanning status of any referenced image is **Scanning**, the status for the OCI image index as a whole will also be **Scanning**. The scan for the index is considered successful only if all referenced images are successfully scanned. It is considered limited successful when not all referenced images are successfully scanned but at least one of referenced image is successfully scanned, otherwise it is considered failed.
|
||||
|
||||
|
||||
|
||||
|
||||
When an OCI image index is successfully scanned, the summary of the vulnerability report for the OCI image index is aggregated from the individual scan results of the the artifacts referenced by the index. The vulnerability report will show both sets of statistics.
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
title: Schedule Scans
|
||||
weight: 40
|
||||
---
|
||||
|
||||
You can set policies to control when vulnerability scanning should run.
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Interrogation Services**.
|
||||
1. Select the **Vulnerability** tab and click the **Edit** button next to **Schedule to scan all**.
|
||||
1. Use the drop down-menu to select how often to run scans.
|
||||
|
||||
|
||||
|
||||
* **None**: No scans are scheduled.
|
||||
* **Hourly**: Run a scan at the beginning of every hour.
|
||||
* **Daily**: Run a scan at midnight every day.
|
||||
* **Weekly**: Run a scan at midnight every Saturday.
|
||||
* **Custom**: Run a scan according to a `cron` job.
|
||||
1. Click **Save**.
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
title: Building, Customizing, and Contributing to Harbor
|
||||
weight: 20
|
||||
---
|
||||
|
||||
This section describes how developers can build from Harbor source code, customize their deployments, and contribute to the open-source Harbor project.
|
||||
|
||||
See also the list of [Articles from the Harbor Community](https://github.com/goharbor/harbor/blob/master/docs/README.md#articles-from-the-community).
|
||||
|
|
@ -1,179 +0,0 @@
|
|||
---
|
||||
title: Build Harbor from Source Code
|
||||
---
|
||||
|
||||
This guide provides instructions for developers to build and run Harbor from source code.
|
||||
|
||||
## Step 1: Prepare for a build environment for Harbor
|
||||
|
||||
Harbor is deployed as several Docker containers and most of the code is written in Go language. The build environment requires Docker, Docker Compose and golang development environment. Please install the below prerequisites:
|
||||
|
||||
| Software | Required Version |
|
||||
| -------------- | ---------------- |
|
||||
| docker | 17.05 + |
|
||||
| docker-compose | 1.18.0 + |
|
||||
| python | 2.7 + |
|
||||
| git | 1.9.1 + |
|
||||
| make | 3.81 + |
|
||||
| golang\* | 1.7.3 + |
|
||||
|
||||
\*optional, required only if you use your own Golang environment.
|
||||
|
||||
## Step 2: Getting the source code
|
||||
|
||||
```sh
|
||||
git clone https://github.com/goharbor/harbor
|
||||
```
|
||||
|
||||
## Step 3: Building and installing Harbor
|
||||
|
||||
### Configuration
|
||||
|
||||
Copy the file **make/harbor.yml.tmp** to **make/harbor.yml**, and make necessary configuration changes such as hostname, admin password and mail server. Refer to [Harbor Installation and Configuration](../install-config/_index.md) for more info.
|
||||
|
||||
```sh
|
||||
cd harbor
|
||||
vi make/harbor.yml
|
||||
```
|
||||
|
||||
### Compiling and Running
|
||||
|
||||
You can compile the code by one of the three approaches:
|
||||
|
||||
#### I. Build with official Golang image
|
||||
|
||||
- Get official Golang image from docker hub:
|
||||
|
||||
```sh
|
||||
docker pull golang:1.12.5
|
||||
```
|
||||
|
||||
- Build, install and bring up Harbor without Notary:
|
||||
|
||||
```sh
|
||||
make install GOBUILDIMAGE=golang:1.12.5 COMPILETAG=compile_golangimage
|
||||
```
|
||||
|
||||
- Build, install and bring up Harbor with Notary:
|
||||
|
||||
```sh
|
||||
make install GOBUILDIMAGE=golang:1.12.5 COMPILETAG=compile_golangimage NOTARYFLAG=true
|
||||
```
|
||||
|
||||
- Build, install and bring up Harbor with Clair:
|
||||
|
||||
```sh
|
||||
make install GOBUILDIMAGE=golang:1.12.5 COMPILETAG=compile_golangimage CLAIRFLAG=true
|
||||
```
|
||||
|
||||
#### II. Compile code with your own Golang environment, then build Harbor
|
||||
|
||||
- Move source code to `$GOPATH`
|
||||
|
||||
```sh
|
||||
mkdir $GOPATH/src/github.com/goharbor/
|
||||
cd ..
|
||||
mv harbor $GOPATH/src/github.com/goharbor/.
|
||||
```
|
||||
|
||||
- Build, install and run Harbor without Notary and Clair:
|
||||
|
||||
```sh
|
||||
cd $GOPATH/src/github.com/goharbor/harbor
|
||||
$ make install
|
||||
```
|
||||
|
||||
- Build, install and run Harbor with Notary and Clair:
|
||||
|
||||
```sh
|
||||
cd $GOPATH/src/github.com/goharbor/harbor
|
||||
make install -e NOTARYFLAG=true CLAIRFLAG=true
|
||||
```
|
||||
|
||||
### Verify your installation
|
||||
|
||||
If everything worked properly, you will see this message:
|
||||
|
||||
```sh
|
||||
...
|
||||
Start complete. You can visit harbor now.
|
||||
```
|
||||
|
||||
Refer to [Reconfigure Harbor and Manage the Harbor Lifecycle](../install-config/reconfigure-manage-lifecycle.md) for more information about managing your Harbor instance.
|
||||
|
||||
## Appendix
|
||||
|
||||
- Using the Makefile
|
||||
|
||||
The `Makefile` contains these configurable parameters:
|
||||
|
||||
| Variable | Description |
|
||||
| ------------------- | ---------------------------------------------------------------- |
|
||||
| BASEIMAGE | Container base image, default: photon |
|
||||
| DEVFLAG | Build model flag, default: dev |
|
||||
| COMPILETAG | Compile model flag, default: compile_normal (local golang build) |
|
||||
| NOTARYFLAG | Notary mode flag, default: false |
|
||||
| CLAIRFLAG | Clair mode flag, default: false |
|
||||
| TRIVYFLAG | Trivy mode flag, default: false |
|
||||
| HTTPPROXY | NPM http proxy for Clarity UI builder |
|
||||
| REGISTRYSERVER | Remote registry server IP address |
|
||||
| REGISTRYUSER | Remote registry server user name |
|
||||
| REGISTRYPASSWORD | Remote registry server user password |
|
||||
| REGISTRYPROJECTNAME | Project name on remote registry server |
|
||||
| VERSIONTAG | Harbor images tag, default: dev |
|
||||
| PKGVERSIONTAG | Harbor online and offline version tag, default:dev |
|
||||
|
||||
- Predefined targets:
|
||||
|
||||
| Target | Description |
|
||||
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------- |
|
||||
| all | prepare env, compile binaries, build images and install images |
|
||||
| prepare | prepare env |
|
||||
| compile | compile ui and jobservice code |
|
||||
| compile_portal | compile portal code |
|
||||
| compile_ui | compile ui binary |
|
||||
| compile_jobservice | compile jobservice binary |
|
||||
| build | build Harbor docker images (default: using build_photon) |
|
||||
| build_photon | build Harbor docker images from Photon OS base image |
|
||||
| install | compile binaries, build images, prepare specific version of compose file and startup Harbor instance |
|
||||
| start | startup Harbor instance (set NOTARYFLAG=true when with Notary) |
|
||||
| down | shutdown Harbor instance (set NOTARYFLAG=true when with Notary) |
|
||||
| package_online | prepare online install package |
|
||||
| package_offline | prepare offline install package |
|
||||
| pushimage | push Harbor images to specific registry server |
|
||||
| clean all | remove binary, Harbor images, specific version docker-compose file, specific version tag and online/offline install package |
|
||||
| cleanbinary | remove ui and jobservice binary |
|
||||
| cleanimage | remove Harbor images |
|
||||
| cleandockercomposefile | remove specific version docker-compose |
|
||||
| cleanversiontag | remove specific version tag |
|
||||
| cleanpackage | remove online/offline install package |
|
||||
|
||||
#### EXAMPLE:
|
||||
|
||||
#### Push Harbor images to specific registry server
|
||||
|
||||
```sh
|
||||
make pushimage -e DEVFLAG=false REGISTRYSERVER=[$SERVERADDRESS] REGISTRYUSER=[$USERNAME] REGISTRYPASSWORD=[$PASSWORD] REGISTRYPROJECTNAME=[$PROJECTNAME]
|
||||
```
|
||||
|
||||
**Note**: need add "/" on end of REGISTRYSERVER. If REGISTRYSERVER is not set, images will be pushed directly to Docker Hub.
|
||||
|
||||
```sh
|
||||
make pushimage -e DEVFLAG=false REGISTRYUSER=[$USERNAME] REGISTRYPASSWORD=[$PASSWORD] REGISTRYPROJECTNAME=[$PROJECTNAME]
|
||||
```
|
||||
|
||||
#### Clean up binaries and images of a specific version
|
||||
|
||||
```sh
|
||||
make clean -e VERSIONTAG=[TAG]
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
If new code has been added to Github, the git commit TAG will change. Better use this command to clean up images and files of previous TAG.
|
||||
{{< /note >}}
|
||||
|
||||
#### By default, the make process create a development build. To create a release build of Harbor, set the below flag to false.
|
||||
|
||||
```sh
|
||||
make XXXX -e DEVFLAG=false
|
||||
```
|
||||
|
|
@ -1,96 +0,0 @@
|
|||
---
|
||||
title: View and Test the Harbor REST API via Swagger
|
||||
---
|
||||
|
||||
A Swagger file is provided for viewing and testing Harbor REST API.
|
||||
|
||||
## Viewing Harbor REST API
|
||||
|
||||
* Open the file **swagger.yaml** under the _docs_ directory in Harbor project
|
||||
* Paste all its content into the online Swagger Editor at http://editor.swagger.io. The descriptions of Harbor API will be shown on the right pane of the page.
|
||||
|
||||
|
||||
|
||||
## Testing Harbor REST API
|
||||
From time to time, you may need to mannually test Harbor REST API. You can deploy the Swagger file into Harbor's service node. Suppose you install Harbor through online or offline installer, you should have a Harbor directory after you un-tar the installer, such as `~/harbor`.
|
||||
|
||||
{{< danger >}}
|
||||
When using Swagger to send REST requests to Harbor, you may alter the data of Harbor accidentally. For this reason, we do **not** recommended using Swagger against a production Harbor instance.
|
||||
{{< /danger >}}
|
||||
|
||||
* Download `prepare-swagger.sh` and `swagger.yaml` under the `docs` directory to your local Harbor directory, e.g. `~/harbor`.
|
||||
|
||||
```sh
|
||||
wget https://raw.githubusercontent.com/goharbor/harbor/master/docs/prepare-swagger.sh https://raw.githubusercontent.com/goharbor/harbor/master/docs/swagger.yaml
|
||||
```
|
||||
|
||||
* Edit the script file `prepare-swagger.sh`.
|
||||
|
||||
```sh
|
||||
vi prepare-swagger.sh
|
||||
```
|
||||
|
||||
* Change the SCHEME to the protocol scheme of your Harbor server.
|
||||
|
||||
```sh
|
||||
SCHEME=<HARBOR_SERVER_SCHEME>
|
||||
```
|
||||
|
||||
* Change the `SERVER_IP` to the IP address of your Harbor server.
|
||||
|
||||
```sh
|
||||
SERVER_IP=<HARBOR_SERVER_DOMAIN>
|
||||
```
|
||||
|
||||
* Change the file mode.
|
||||
|
||||
```sh
|
||||
chmod +x prepare-swagger.sh
|
||||
```
|
||||
|
||||
* Run the shell script. It downloads a Swagger package and extracts files into the `../static` directory.
|
||||
|
||||
```sh
|
||||
./prepare-swagger.sh
|
||||
```
|
||||
|
||||
* Edit the `docker-compose.yml` file under your local Harbor directory.
|
||||
|
||||
```sh
|
||||
vi docker-compose.yml
|
||||
```
|
||||
|
||||
* Add two lines to the file `docker-compose.yml` under the section `ui.volumes`.
|
||||
|
||||
```yaml
|
||||
# ...
|
||||
ui:
|
||||
# ...
|
||||
volumes:
|
||||
- ./common/config/ui/app.conf:/etc/core/app.conf:z
|
||||
- ./common/config/ui/private_key.pem:/etc/core/private_key.pem:z
|
||||
- /data/secretkey:/etc/core/key:z
|
||||
- /data/ca_download/:/etc/core/ca/:z
|
||||
## add two lines as below ##
|
||||
- ../src/ui/static/vendors/swagger-ui-2.1.4/dist:/harbor/static/vendors/swagger
|
||||
- ../src/ui/static/resources/yaml/swagger.yaml:/harbor/static/resources/yaml/swagger.yaml
|
||||
# ...
|
||||
```
|
||||
|
||||
* Recreate Harbor containers
|
||||
|
||||
```docker
|
||||
docker-compose down -v && docker-compose up -d
|
||||
```
|
||||
|
||||
* Because a session ID is usually required by Harbor API, **you should log in first from a browser.**
|
||||
* Open another tab in the same browser so that the session is shared between tabs.
|
||||
* Enter the URL of the Swagger page in Harbor as below. The ```<HARBOR_SERVER>``` should be replaced by the IP address or the hostname of the Harbor server.
|
||||
|
||||
```text
|
||||
http://<HARBOR_SERVER>/static/vendors/swagger/index.html
|
||||
```
|
||||
|
||||
* You should see a Swagger UI page with Harbor API _swagger.yaml_ file loaded in the same domain, **be aware that your REST request submitted by Swagger may change the data of Harbor**.
|
||||
|
||||
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
title: Customize the Look and Feel of Harbor
|
||||
---
|
||||
|
||||
The primary look & feel of Harbor supports to be customized with several simple steps. All the relevant customization in configurations are saved in the `setting.json` file under `$HARBOR_DIR/src/portal/src` folder with `json` format and will be loaded when Harbor is launched.
|
||||
|
||||
## Configure
|
||||
|
||||
Open the `setting.json` file, you'll see the default content as shown below:
|
||||
|
||||
```json
|
||||
{
|
||||
"headerBgColor": "#004a70",
|
||||
"headerLogo": "",
|
||||
"loginBgImg": "",
|
||||
"appTitle": "",
|
||||
"product": {
|
||||
"name": "Harbor",
|
||||
"introduction": {
|
||||
"zh-cn": "",
|
||||
"es-es": "",
|
||||
"en-us": ""
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Change the values of configuration if you want to override the default style to your own. Here are references:
|
||||
|
||||
* **headerBgColor**: Background color of the page header, support either HEX or RGB value. e.g: `#004a70` and `rgb(210,110,235)`.
|
||||
* **headerLogo**: Name path of the logo image in the header, e.g: 'logo.png'. The image file should be put in the `images` folder.
|
||||
* **loginBgImg**: Name path of the background image displayed in the login page, e.g: 'login_bg.png'. The image file should be put in the `images` folder. Suggest the size of this image should be bigger than 800px*600px.
|
||||
* **Product**: Contain metadata / description of the product.
|
||||
- **title**: The full product title displayed in the login page.
|
||||
- **company**: Name of the company publishing the product.
|
||||
- **name**: Name of the product.
|
||||
- **introductions**: The introduction about the product with different languages, which are displayed in the `About` dialog.
|
||||
|
||||
## Build
|
||||
|
||||
Once the `setting.json` configurations has been updated, re-[build](#configure) your product to apply the new changes.
|
||||
|
|
@ -1,73 +0,0 @@
|
|||
---
|
||||
title: Developing for Internationalization
|
||||
---
|
||||
|
||||
{{< note >}}
|
||||
All the files you created should use UTF-8 encoding.
|
||||
{{< /note >}}
|
||||
|
||||
Steps to localize the UI in your language
|
||||
|
||||
1. In the folder `src/portal/src/i18n/lang`, copy json file `en-us-lang.json` to a new file and rename it to `<language>-<locale>-lang.json` .
|
||||
|
||||
The file contains a JSON object including all the key-value pairs of UI strings:
|
||||
|
||||
```javascript
|
||||
{
|
||||
"APP_TITLE": {
|
||||
"VMW_HARBOR": "Harbor",
|
||||
"HARBOR": "Harbor",
|
||||
// ...
|
||||
},
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
In the file `<language>-<locale>-lang.json`, translate all the values into your language. Do not change any keys.
|
||||
|
||||
2. After creating your language file, you should add it to the language supporting list.
|
||||
|
||||
Locate the file `src/portal/src/app/shared/shared.const.ts`.
|
||||
|
||||
Append `<language>-<locale>` to the language supporting list:
|
||||
|
||||
```typescript
|
||||
export const supportedLangs = ['en-us', 'zh-cn', '<language>-<locale>'];
|
||||
```
|
||||
|
||||
Define the language display name and append it to the name list:
|
||||
|
||||
```typescript
|
||||
export const languageNames = {
|
||||
"en-us": "English",
|
||||
"zh-cn": "中文简体",
|
||||
"<language>-<locale>": "<DISPLAY_NAME>"
|
||||
};
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Don't miss the comma before the new key-value item you've added.
|
||||
{{< /note >}}
|
||||
|
||||
3. Enable the new language in the view.
|
||||
|
||||
Locate the file `src/portal/src/app/base/navigator/navigator.component.html` and then find the following code piece:
|
||||
|
||||
```html
|
||||
<div class="dropdown-menu">
|
||||
<a href="javascript:void(0)" clrDropdownItem (click)='switchLanguage("en-us")' [class.lang-selected]='matchLang("en-us")'>English</a>
|
||||
<a href="javascript:void(0)" clrDropdownItem (click)='switchLanguage("zh-cn")' [class.lang-selected]='matchLang("zh-cn")'>中文简体</a>
|
||||
</div>
|
||||
```
|
||||
|
||||
Add a new menu item for your language:
|
||||
|
||||
```html
|
||||
<div class="dropdown-menu">
|
||||
<a href="javascript:void(0)" clrDropdownItem (click)='switchLanguage("en-us")' [class.lang-selected]='matchLang("en-us")'>English</a>
|
||||
<a href="javascript:void(0)" clrDropdownItem (click)='switchLanguage("zh-cn")' [class.lang-selected]='matchLang("zh-cn")'>中文简体</a>
|
||||
<a href="javascript:void(0)" clrDropdownItem (click)='switchLanguage("<language>-<locale>")' [class.lang-selected]='matchLang("<language>-<locale>")'>DISPLAY_NAME</a>
|
||||
</div>
|
||||
```
|
||||
|
||||
4. Next, refer to [Build Harbor from Source Code](compile-guide.md) to rebuild and restart Harbor.
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
---
|
||||
title: E2E (API) Python Based Test Scripting Guide
|
||||
draft: true
|
||||
---
|
||||
|
||||
#### Preparation ####
|
||||
|
||||
After getting Harbor source code (git clone https://github.com/goharbor/harbor.git), Harbor E2E API test scripts can be found in tests/apitests/python directory.
|
||||
|
||||
Before scripting, please make sure swagger client has been made by "make swagger_client", then archive "harborclient" will be made
|
||||
|
||||
1. `git clone https://github.com/goharbor/harbor.git`
|
||||
|
||||
2. `cd harbor`
|
||||
|
||||
3. `make swagger_client`
|
||||
|
||||
4. `cd harborclient/`
|
||||
|
||||
|
||||
We use $HARBORCLIENT_PATH represent the path of "harborclient" you've made by "make swagger_client".
|
||||
|
||||
Deploy Harbor instance for testing, and we will use $HARBOR_IP_ADDR to represent the deployed Harbor in this document.
|
||||
|
||||
Harbor E2E API test scripts will import python library under archive "harborclient", please set OS environment variant for Harbor E2E API test scripts:
|
||||
|
||||
|
||||
1. `export HARBOR_HOST=$HARBOR_IP_ADDR`
|
||||
2. `export SWAGGER_CLIENT_PATH=$HARBORCLIENT_PATH`
|
||||
|
||||
Until now, we have all preparation work done.
|
||||
|
||||
#### Scripting ####
|
||||
|
||||
As you can see, we will use python library made by "make swagger_client", in this library, we have all API functions and models, but for more convenience we encapsulate one more level in archive "library", so the script structure is as bellow:
|
||||
|
||||
-library/
|
||||
|
||||
-test_project_level_policy_content_trust.py
|
||||
|
||||
-test_project_quota.py
|
||||
|
||||
-test_retention.py
|
||||
|
||||
-...
|
||||
|
||||
You can add both library code and script code, since not all APIs have been encapsulated.
|
||||
|
||||
|
||||
#### Manual Execution Example ####
|
||||
|
||||
root@harbor:/harbor/code/harbor# `python ./tests/apitests/python/test_add_sys_label_to_tag.py`
|
||||
|
||||
2020-03-11 13:40:07,269 DEBUG Starting new HTTPS connection (1): 1.1.1.1:443
|
||||
send: 'POST /api/v2.0/users HTTP/1.1\r\nHost: 1.1.1.1\r\nAccept-Encoding: identity\r\nContent-Length: 156\r\nContent-Type: application/json\r\nAccept: application/json\r\nAuthorization: Basic YWRtaW46SGFyYm9yMTIzNDU=\r\nUser-Agent: Swagger-Codegen/1.0.0/python\r\n\r\n{"username": "user-1583934007059", "role_id": 0, "password": "xxxxxxxx", "email": "realname-1583934007059@vmware.com", "realname": "realname-1583934007059"}'
|
||||
reply: 'HTTP/1.1 201 Created\r\n'
|
||||
header: Server: nginx
|
||||
header: Date: Wed, 11 Mar 2020 13:40:07 GMT
|
||||
header: Content-Length: 0
|
||||
header: Connection: keep-alive
|
||||
header: Location: /api/v2.0/users/9
|
||||
header: Set-Cookie: sid=2e05f902f345b855ec33221ade1c6d09; Path=/; Secure; HttpOnly
|
||||
header: X-Request-Id: 9ba11b26-2cdb-432f-878e-3fed04fa61b1
|
||||
header: Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
|
||||
header: X-Frame-Options: DENY
|
||||
header: Content-Security-Policy: frame-ancestors 'none'
|
||||
2020-03-11 13:40:07,482 DEBUG https://1.1.1.1:443 "POST /api/v2.0/users HTTP/1.1" 201 0
|
||||
2020-03-11 13:40:07,483 DEBUG response body:
|
||||
|
||||
......
|
||||
|
||||
......
|
||||
|
||||
......
|
||||
|
||||
#### How To Trigger Script In CI ####
|
||||
|
||||
If you like to have your scripts running in CI which is for verification of pull requests, please add your scripts into *https://github.com/goharbor/harbor/blob/master/tests/robot-cases/Group0-BAT/API_DB.robot* file, then scripts can be triggered once there is a pull request.
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
#!/bin/bash
|
||||
SCHEME=http
|
||||
SERVER_IP=reg.mydomain.com
|
||||
set -e
|
||||
echo "Doing some clean up..."
|
||||
rm -f *.tar.gz
|
||||
echo "Downloading Swagger UI release package..."
|
||||
wget https://github.com/swagger-api/swagger-ui/archive/v2.1.4.tar.gz -O swagger.tar.gz
|
||||
echo "Untarring Swagger UI package to the static file path..."
|
||||
mkdir -p ../src/ui/static/vendors
|
||||
tar -C ../src/ui/static/vendors -zxf swagger.tar.gz swagger-ui-2.1.4/dist
|
||||
echo "Executing some processes..."
|
||||
sed -i.bak 's/http:\/\/petstore\.swagger\.io\/v2\/swagger\.json/'$SCHEME':\/\/'$SERVER_IP'\/static\/resources\/yaml\/swagger\.yaml/g' \
|
||||
../src/ui/static/vendors/swagger-ui-2.1.4/dist/index.html
|
||||
sed -i.bak '/jsonEditor: false,/a\ validatorUrl: null,' ../src/ui/static/vendors/swagger-ui-2.1.4/dist/index.html
|
||||
mkdir -p ../src/ui/static/resources/yaml
|
||||
cp swagger.yaml ../src/ui/static/resources/yaml
|
||||
sed -i.bak 's/host: localhost/host: '$SERVER_IP'/g' ../src/ui/static/resources/yaml/swagger.yaml
|
||||
sed -i.bak 's/ \- http$/ \- '$SCHEME'/g' ../src/ui/static/resources/yaml/swagger.yaml
|
||||
echo "Finish preparation for the Swagger UI."
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
title: Registry Landscape
|
||||
---
|
||||
|
||||
The cloud native ecosystem is moving rapidly—registries and their feature sets are no exception. We've made our best effort to survey the container registry landscape and compare to our core feature set.
|
||||
|
||||
If you find something outdated or outright erroneous, please submit a PR and we'll fix it right away.
|
||||
|
||||
Table updated on 10/21/2019 against Harbor 1.9.
|
||||
|
||||
| Feature | Harbor | Docker Trusted Registry | Quay | Cloud Providers (GCP, AWS, Azure) | Docker Distribution | Artifactory | GitLab |
|
||||
| -------------: | :----: | :---------------------: | :-----: | :-------------------------------: | :-----------------: | :---------: | :------: |
|
||||
| Ability to Determine Version of Binaries in Containers | ✓ | ✓ | ✓ | ✗ | ✗ | ? | ? |
|
||||
| Artifact Repository (rpms, git, jar, etc) | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | partial |
|
||||
| Audit Logs | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ |
|
||||
| Content Trust and Validation | ✓ | ✓ | ✗ | ✗ | partial | partial | ✗ |
|
||||
| Custom TLS Certificates | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ |
|
||||
| Helm Chart Repository Manager | ✓ | ✗ | partial | ✗ | ✗ | ✓ | ✗ |
|
||||
| LDAP-based Auth | ✓ | ✓ | ✓ | partial | ✗ | ✓ | ✓ |
|
||||
| Local Auth | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ |
|
||||
| Multi-Tenancy (projects, teams, namespaces, etc) | ✓ | ✓ | ✓ | partial | ✗ | ✓ | ✓ |
|
||||
| Open Source | ✓ | partial | ✗ | ✗ | ✓ | partial | partial |
|
||||
| Project Quotas (by image count & storage consumption) | ✓ | ✗ | ✗ | partial | ✗ | ✗ | ✗ |
|
||||
| Replication between instances | ✓ | ✓ | ✓ | n/a | ✗ | ✓ | ✗ |
|
||||
| Replication between non-instances | ✓ | ✗ | ✓ | n/a | ✗ | ✗ | ✗ |
|
||||
| Robot Accounts for Helm Charts | ✓ | ✗ | ✗ | ? | ✗ | ✗ | ✗ |
|
||||
| Robot Accounts for Images | ✓ | ? | ✓ | ? | ✗ | ? | ? |
|
||||
| Role-Based Access Control | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | ✗ |
|
||||
| Single Sign On (OIDC) | ✓ | ✓ | ✓ | ✓ | ✗ | partial | ✗ |
|
||||
| Tag Retention Policy | ✓ | ✗ | partial | ✗ | ✗ | ✗ | ✗ |
|
||||
| Upstream Registry Proxy Cache | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✗ |
|
||||
| Vulnerability Scanning & Monitoring | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | partial |
|
||||
| Vulnerability Scanning Plugin Framework | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
|
||||
| Vulnerability Allowlisting | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
|
||||
| Webhooks | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,96 +0,0 @@
|
|||
---
|
||||
title: Developing the Harbor Frontend
|
||||
---
|
||||
|
||||
If you already have a harbor backend environment, you can build a frontend development environment with the following configuration.
|
||||
|
||||
1. Create the file proxy.config.json in the directory harbor/src/portal，and config it according to the sample below.
|
||||
|
||||
**NOTE:** You should replace “$IP_ADDRESS” with your own ip address.
|
||||
|
||||
```json
|
||||
{
|
||||
"/api/*": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"changeOrigin": true,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/service/*": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/c/login": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/sign_in": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/c/log_out": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/sendEmail": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/language": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/reset": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/userExists": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/reset_password": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/i18n/lang/*.json": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug",
|
||||
"pathRewrite": { "^/src$": "" }
|
||||
},
|
||||
"/chartrepo": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/*.json": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
2. Open the terminal and run the following command，install npm packages as 3rd-party dependencies.
|
||||
|
||||
```sh
|
||||
cd harbor/src/portal
|
||||
npm install
|
||||
```
|
||||
|
||||
3. Execute the following command，serve Harbor locally.
|
||||
|
||||
```sh
|
||||
npm run start
|
||||
```
|
||||
|
||||
4. Then you can visit the Harbor by address: https://localhost:4200.
|
||||
|
|
@ -1,66 +0,0 @@
|
|||
---
|
||||
title: Using Make
|
||||
---
|
||||
|
||||
## Variables
|
||||
|
||||
Variable | Description
|
||||
-------------------|-------------
|
||||
BASEIMAGE | Container base image, default: photon
|
||||
DEVFLAG | Build model flag, default: dev
|
||||
COMPILETAG | Compile model flag, default: compile_normal (local golang build)
|
||||
GOBUILDIMAGE | Golang image to compile harbor go source code.
|
||||
NOTARYFLAG | Whether to enable notary in harbor, default:false
|
||||
HTTPPROXY | Clarity proxy to build UI.
|
||||
|
||||
## Targets
|
||||
|
||||
Target | Description
|
||||
--------------------|-------------
|
||||
all | prepare env, compile binaries, build images and install images
|
||||
prepare | prepare env
|
||||
compile | compile ui and jobservice code
|
||||
compile_portal | compile portal code
|
||||
compile_core | compile core binary
|
||||
compile_jobservice | compile jobservice binary
|
||||
build | build Harbor docker images (default: using build_photon)
|
||||
build_photon | build Harbor docker images from Photon OS base image
|
||||
install | compile binaries, build images, prepare specific version of compose file and startup Harbor instance
|
||||
start | startup Harbor instance
|
||||
down | shutdown Harbor instance
|
||||
package_online | prepare online install package
|
||||
package_offline | prepare offline install package
|
||||
pushimage | push Harbor images to specific registry server
|
||||
clean all | remove binary, Harbor images, specific version docker-compose file, specific version tag and online/offline install package
|
||||
cleanbinary | remove ui and jobservice binary
|
||||
cleanimage | remove Harbor images
|
||||
cleandockercomposefile | remove specific version docker-compose
|
||||
cleanversiontag | remove specific version tag
|
||||
cleanpackage | remove online/offline install package
|
||||
version | set harbor version
|
||||
|
||||
## Examples
|
||||
|
||||
### Build and run harbor from source code
|
||||
|
||||
```sh
|
||||
make install GOBUILDIMAGE=golang:1.14.5 COMPILETAG=compile_golangimage NOTARYFLAG=true
|
||||
```
|
||||
|
||||
### Package offline installer
|
||||
|
||||
```sh
|
||||
make package_offline GOBUILDIMAGE=golang:1.14.5 COMPILETAG=compile_golangimage NOTARYFLAG=true
|
||||
```
|
||||
|
||||
### Start harbor with notary
|
||||
|
||||
```sh
|
||||
make -e NOTARYFLAG=true start
|
||||
```
|
||||
|
||||
### Stop harbor with notary
|
||||
|
||||
```sh
|
||||
make -e NOTARYFLAG=true down
|
||||
```
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 3.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 6.4 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.8 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 95 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 231 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 114 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 4.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.2 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.4 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 8.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 6.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.6 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 118 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
|
|
@ -1,5 +0,0 @@
|
|||
<svg version="1.1" width="36" height="36" viewBox="0 0 36 36" preserveAspectRatio="xMidYMid meet" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<title>bell-outline-badged</title>
|
||||
<path class="clr-i-outline--badged clr-i-outline-path-1--badged" d="M18,34.28A2.67,2.67,0,0,0,20.58,32H15.32A2.67,2.67,0,0,0,18,34.28Z"></path><path class="clr-i-outline--badged clr-i-outline-path-2--badged" d="M32.51,27.83A14.4,14.4,0,0,1,30,24.9a12.63,12.63,0,0,1-1.35-4.81V15.15a10.92,10.92,0,0,0-.16-1.79,7.44,7.44,0,0,1-2.24-.84,8.89,8.89,0,0,1,.4,2.64v4.94a14.24,14.24,0,0,0,1.65,5.85,16.17,16.17,0,0,0,2.44,3H5.13a16.17,16.17,0,0,0,2.44-3,14.24,14.24,0,0,0,1.65-5.85V15.15A8.8,8.8,0,0,1,18,6.31a8.61,8.61,0,0,1,4.76,1.44A7.49,7.49,0,0,1,22.5,6c0-.21,0-.42,0-.63a10.58,10.58,0,0,0-3.32-1V3.11a1.33,1.33,0,1,0-2.67,0V4.42A10.81,10.81,0,0,0,7.21,15.15v4.94A12.63,12.63,0,0,1,5.86,24.9a14.4,14.4,0,0,1-2.47,2.93,1,1,0,0,0-.34.75v1.36a1,1,0,0,0,1,1h27.8a1,1,0,0,0,1-1V28.58A1,1,0,0,0,32.51,27.83Z"></path><circle class="clr-i-outline--badged clr-i-outline-path-1--badged clr-i-badge" cx="30" cy="6" r="5"></circle>
|
||||
<rect x="0" y="0" width="36" height="36" fill-opacity="0"/>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 1.2 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 208 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 934 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 112 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 86 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 220 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 308 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 198 KiB |
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue