upstream/harbor
1
0
Fork 0
mirror of https://github.com/goharbor/harbor synced 2024-09-20 15:25:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

update docs

Browse Source
This commit is contained in:
Henry Zhang 2016-12-06 00:41:05 +08:00
parent 8333e54d75
commit 8359c91e66
2 changed files with 37 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
docs/installation_guide_ova.md
View File

@ -1,5 +1,12 @@
# Installing and Configuring Harbor on vSphere as Virtual Appliance
* [Prerequisites](#prerequisites)
* [Planning for installation](#planning-for-installation)
* [Installation](#installation)
* [Getting Certificate of Harbor's CA](#getting-certificate-of-harbors-ca)
* [Reconfiguration](#reconfiguration)
* [Troubleshooting](#troubleshooting)
This guide walks you through the steps about installing and configuring Harbor on vSphere as an virtual appliance. If you are installing Harbor on a Linux host, refer to this **[Installation Guide](installation_guide.md)**.
## Prerequisites
@ -18,7 +25,7 @@ By default, Harbor stores user information in an internal database. Harbor can a
Harbor uses HTTPS for secure communication by default. A self-signed certificate is generated at first boot based on its FQDN (Fully Qualified Domain Name) or IP address. A Docker client or a VCH (Virtual Container Host) needs to trust the certificate of Harbor's CA (Certificate Authority) in order to interact with Harbor.
Harbor always tries to generate a self-signed certificate based on its FQDN. Therefore, its IP address must have a FQDN associated with it in the DNS server. If Harbor cannot resolve its IP address to a FQDN, it generates the self-signed certificate using its IP address. In this case, Harbor can only be accessed by IP address. When Harbor's IP address or FQDN is changed, the self-signed certificate will be re-generated.
Harbor always tries to generate a self-signed certificate based on its FQDN. Therefore, its IP address must have a FQDN associated with it in the DNS server. If Harbor cannot resolve its IP address to a FQDN, it generates the self-signed certificate using its IP address. In this case, Harbor can only be accessed by IP address. When Harbor's IP address or FQDN is changed, the self-signed certificate will be re-generated after a reboot.
Harbor's self-generated certificate can be replaced by supplying a certificate signed by other CAs in OVA's settings.
@ -123,12 +130,12 @@ For the purpose of generating a self-signed certificate, it is recommended that
12. When the appliance is ready, check from vSphere Web Client for its IP address. Open a browser and type in the URL `http(s)://harbor_ip_address` or `http(s)://harbor_host_name`. Log in as the admin user and verify Harbor has been successfully installed.
13. For information on how to use Harbor, please refer to [User Guide of Harbor](user_guide.md).
13. For information on how to use Harbor, please refer to [User Guide of Harbor Virtual Appliance](user_guide_ova.md).
## Getting Certificate of Harbor's CA
By default, Harbor uses a self-signed certificate in HTTPS. A Docker client or a VCH needs to trust the certificate of Harbor's CA in order to interact with Harbor.
To download the certificate of Harbor's CA and import into a Docker client, follow the below steps:
By default, Harbor uses a self-signed certificate in HTTPS. A Docker client or a VCH needs to trust the self-signed certificate of Harbor's CA in order to interact with Harbor.
To download the certificate of Harbor's CA and import into a Docker client, follow the below steps. If a certificate issued by a public known CA is used, the below steps are not needed.
1. Log in Harbor's UI as an admin user.
2. Click on the admin's name at the upper left corner and select **"About"** from the drop-down menu.
@ -147,7 +154,7 @@ To download the certificate of Harbor's CA and import into a Docker client, foll
cp ca.crt /etc/docker/certs.d/<Harbor_IP>/
```
**Note:** If you run the above two sets of commands, Harbor can be accessed by both FQDN and IP address.
**Note:** If you run both of the above two sets of commands, Harbor can be accessed by either FQDN or IP address.
5. Run `docker login` command to verify that HTTPS is working.
@ -165,10 +172,10 @@ If you want to change the properties of Harbor, follow the below steps:
![ova](img/ova/vapp_options.png)
4. **Power on** the VM.
4. **Power on** the VM and Harbor will reconfigure itself based on the new settings.
**Notes:**
1. The authentication mode can only be set once before the firtst boot. Subsequent modification of this option does not have any effect.
**Note:**
1. The **Authentication Mode** can only be set once before the firtst boot. Subsequent modification of this option does not have any effect.
2. The initial admin password, root password of the virtual appliance, MySQL root password, and all networking properties can not be modified using this method after Harbor's first launch. Modify them by the following approach:
* **Harbor Admin Password**: Change it in Harbor admin portal.
* **Root Password of Virtual Appliance**: Change it by logging in the virtual appliance and doing it in the Linux operating system.

30
docs/user_guide_ova.md
View File

@ -18,7 +18,7 @@ This guide walks you through the fundamentals of using Harbor virtual appliance.
![rbac](img/rbac.png)
Harbor manages images through projects. Users can be added into one project as a member with three different roles:
In Harbor, images are group under projects. To access an image, a user should be added as a member into the project of the image. A member can have one of the three roles:
* **Guest**: Guest has read-only privilege for a specified project.
* **Developer**: Developer has read and write privileges for a project.
@ -85,21 +85,35 @@ You can update or remove a member by clicking the icon on the right.
![browse project](img/new_remove_update_member.png)
##Replicating images
Images replication is used to replicate repositories from one Harbor instance to another.
Images can be replicated between Harbor instances. It can be used to transfer images from one data center to another, or from on-prem registry to an instance in the cloud.
The function is project-oriented, and once the system administrator set a policy to one project, all repositories under the project will be replicated to the remote registry. Each repository will start a job to run. If the project does not exist on the remote registry, a new project will be created automatically, but if it already exists and the user configured in policy has no write privilege to it, the process will fail. When a new repository is pushed to this project or an existing repository is deleted from this project, the same operation will also be replicated to the destination. The member information will not be replicated.
A replication policy needs to be set up on the source instance to govern the replication process.
One key fact about the replication is that only images are replicated between Harbor instances.
Users, roles and other information are not replicated. As such, always keep in mind that the user, roles and policy information is individually managed by each Harbor instance.
There may be a bit of delay during replication according to the situation of the network. If replication job fails due to the network issue, the job will be re-scheduled a few minutes later.
The replication is project-based. When a system administrator sets a policy to a project, all repositories under the project will be replicated to the remote registry. A replication job will be scheduled for each repository.
If the project does not exist on the remote registry, a new project is created automatically.
If the project already exists and the replication user configured in the policy has no write privilege to it,
the process will fail.
Start replication by creating a policy. Click "Add New Policy" on the "Replication" tab, fill the necessary fields, if there is no destination in the list, you need to create one, and then click "OK", a policy for this project will be created. If "Enable" is chosen, the project will be replicated to the remote immediately.
When the policy is first enabled, all images of the project are replicated to the remote registry. Images subsequently pushed to the project on the source registry
will be incrementally replicated to the remote instance. When an image is delete from the source registry, the policy ensures that the remote registry deletes the same image as well.
Please note, the member information will not be replicated.
Depending on the size of the images and the network condition, the replication requires some time to complete. On the remote registry, an image is not available until
all its layers have been synchronized from the source. If replication job fails due to some network issue, the job will be scheduled for a retry after a few minutes.
Always checks the log to see if there is any error of the replication. When a policy is disabled (stopped), Harbor tries to stop all existing jobs. It may take a while
before all jobs finish.
To enable image replication, a policy must first be created. Click "Add New Policy" on the "Replication" tab, fill the necessary fields, if there is no destination in the list, you need to create one, and then click "OK", a policy for this project will be created. If "Enable" is chosen, the project will be replicated to the remote immediately.
**Note:** Set **"Verify Remote Cert"** to off according to the [installation guide](installation_guide_ova.md) if the destination uses a self-signed or untrusted certificate.
![browse project](img/new_create_policy.png)
You can enable, disable or delete a policy in the policy list view. Only policies which are disabled can be edited and only policies which are disabled and have no running jobs can be deleted. If a policy is disabled, the running jobs under it will be stopped.
You can enable, disable or delete a policy in the policy list view. Only policies which are disabled can be edited. Only policies which are disabled and have no running jobs can be deleted. If a policy is disabled, the running jobs under it will be stopped.
Click a policy, jobs which belong to this policy will be listed. A job represents the progress which will replicate a repository of one project to the remote.
Click on a policy, jobs belonging to this policy will be listed. A job represents the progress of replicating a repository to the remote instance.
![browse project](img/new_policy_list.png)
@ -190,4 +204,4 @@ the repository is no longer managed in Harbor, however, the files of the reposit
Next, set **"Garbage Collection"** to true according to the [installation guide](installation_guide_ova.md)(skip this step if this flag has already been set) and reboot the VM, Harbor will perform garbage collection when it boots up.
For more information about GC, please see [GC](https://github.com/docker/docker.github.io/blob/master/registry/garbage-collection.md).
For more information about garbage collection, please see Docker's document on [GC](https://github.com/docker/docker.github.io/blob/master/registry/garbage-collection.md).