mirror of
https://github.com/goharbor/harbor.git
synced 2024-12-23 00:57:44 +01:00
Merge pull request #1035 from hainingzhang/master
update docs and test cases
This commit is contained in:
commit
e37389a75a
@ -1,6 +1,6 @@
|
||||
#User Guide
|
||||
##Overview
|
||||
This guide takes you through the fundamentals of using Harbor. You'll learn how to use Harbor to:
|
||||
This guide walks you through the fundamentals of using Harbor. You'll learn how to use Harbor to:
|
||||
|
||||
* Manage your projects.
|
||||
* Manage members of a project.
|
||||
@ -11,7 +11,7 @@ This guide takes you through the fundamentals of using Harbor. You'll learn how
|
||||
+ Manage destinations.
|
||||
+ Manage replication policies.
|
||||
* Pull and push images using Docker client.
|
||||
* Delete repositories.
|
||||
* Delete repositories and images.
|
||||
|
||||
|
||||
##Role Based Access Control
|
||||
@ -152,24 +152,30 @@ $ docker push 10.117.169.182/demo/ubuntu:14.04
|
||||
|
||||
##Deleting repositories
|
||||
|
||||
Repositories deletion runs in two steps.
|
||||
First, delete repositories in Harbor's UI. This is soft deletion. You can delete the entire repository or just a tag of it.
|
||||
Repository deletion runs in two steps.
|
||||
|
||||
First, delete a repository in Harbor's UI. This is soft deletion. You can delete the entire repository or just a tag of it. After the soft deletion,
|
||||
the repository is no longer managed in Harbor, however, the files of the repository still remains in Harbor's storage.
|
||||
|
||||
![browse project](img/new_delete_repository.png)
|
||||
|
||||
**Note: If both tag A and tag B reference the same image, after deleting tag A, B will also disappear.**
|
||||
**CAUTION: If both tag A and tag B refer to the same image, after deleting tag A, B will also get deleted.**
|
||||
|
||||
Second, delete the real data using registry's garbage colliection(GC).
|
||||
Make sure that no one is pushing images or Harbor is not running at all before you do GC. If someone were to push an image while GC is running, there is the risk that the image's layers will be mistakenly deleted, leading to a corrupted image. So before running GC, a preferred approach is to stop Harbor first.
|
||||
Next, delete the actual files of the repository using the registry's garbage collection(GC). Make sure that no one is pushing images or Harbor is not running at all before you perform a GC. If someone were pushing an image while GC is running, there is a risk that the image's layers will be mistakenly deleted which results in a corrupted image. So before running GC, a preferred approach is to stop Harbor first.
|
||||
|
||||
Run the command on the host which harbor is deployed on.
|
||||
Run the below commands on the host which Harbor is deployed on to preview what files/images will be affect:
|
||||
|
||||
```sh
|
||||
$ docker-compose stop
|
||||
$ docker run -it --name gc --rm --volumes-from deploy_registry_1 registry:2.4.0 garbage-collect [--dry-run] /etc/registry/config.yml
|
||||
$ docker run -it --name gc --rm --volumes-from deploy_registry_1 registry:2.5.0 garbage-collect --dry-run /etc/registry/config.yml
|
||||
```
|
||||
**NOTE:** The above option "--dry-run" will print the progress without removing any data.
|
||||
|
||||
Verify the result of the above test, then use the below commands to perform garbage collection and restart Harbor.
|
||||
|
||||
```sh
|
||||
$ docker run -it --name gc --rm --volumes-from deploy_registry_1 registry:2.5.0 garbage-collect /etc/registry/config.yml
|
||||
$ docker-compose start
|
||||
```
|
||||
|
||||
Option "--dry-run" will print the progress without removing any data.
|
||||
|
||||
About the details of GC, please see [GC](https://github.com/docker/docker.github.io/blob/master/registry/garbage-collection.md).
|
||||
For more information about GC, please see [GC](https://github.com/docker/docker.github.io/blob/master/registry/garbage-collection.md).
|
@ -24,7 +24,7 @@ In below test, user A is non-admin user. User A and project X, Y should be repla
|
||||
3. On a Docker client, log in as User A and run `docker push` to push an image to the project X, e.g. projectX/myimage:v1.
|
||||
4. Push a second image with different tag to project X, e.g. projectX/myimage:v2 .
|
||||
5. Push an image with different name to project X, e.g. projectX/newimage:v1 .
|
||||
6. Run `docker pull` to verify images can be pushed successfully.
|
||||
6. Run `docker pull` to verify images can be pulled successfully.
|
||||
7. In UI, delete the three images one by one.
|
||||
8. On a Docker client, log in as User A and run `docker pull` to pull the three deleted images of project X.
|
||||
9. In UI, delete project X.
|
||||
|
@ -25,7 +25,7 @@ User guide
|
||||
2. Create a project X so that the user has the project admin role.
|
||||
3. On a Docker client, log in as User A and run `docker push` to push an image to project X, e.g. projectX/myimage:v1.
|
||||
4. Push an image with different name to project X, e.g. projectX/newimage:v1 .
|
||||
5. Run `docker pull` to verify images can be pushed successfully.
|
||||
5. Run `docker pull` to verify images can be pulled successfully.
|
||||
6. In UI, delete project X directly. (should fail with errors)
|
||||
7. While keeping the current user A logged on, in a different browser, log in as admin user.
|
||||
8. Under "Admin Options", create a replication policy of project X to another Harbor instance. (Do not need to activate this policy.)
|
||||
|
@ -23,7 +23,7 @@ In below test, user A is non-admin user. User A and project X should be replaced
|
||||
2. Create a project X so that the user has the project admin role.
|
||||
3. On a Docker client, log in as User A and run `docker push` to push an image to the project X, e.g. projectX/myimage:v1.
|
||||
4. Push an image with different name to project X, e.g. projectX/newimage:v1 .
|
||||
5. Run `docker pull` to verify images can be pushed successfully.
|
||||
5. Run `docker pull` to verify images can be pulled successfully.
|
||||
6. In UI, log out user A's session.
|
||||
7. Log in as admin user.
|
||||
8. Under project X, delete the two images one by one.
|
||||
|
@ -24,7 +24,7 @@ User guide
|
||||
1. Log in to UI as user A (non-admin).
|
||||
2. Create a project X so that the user has the project admin role.
|
||||
3. On a Docker client, log in as User A and run `docker push` to push an image to project X, e.g. projectX/myimage:v1.
|
||||
4. Run `docker pull` to verify images can be pushed successfully.
|
||||
4. Run `docker pull` to verify images can be pulled successfully.
|
||||
5. In UI, log out user A.
|
||||
6. Log in as admin user.
|
||||
7. Delete project X. (should fail with errors)
|
||||
@ -35,7 +35,7 @@ User guide
|
||||
# Expected Outcome:
|
||||
* Step 7, deleting project X should fail because there are images under it.
|
||||
* Step 8-9, deleting images of project X and then deleting project X should succeed.
|
||||
* Step 10, there should be logs for delete and create of project X, notice the project name of the deleted operation is displayed differently.
|
||||
* Step 10, there should be logs for deletion and creation of project X.
|
||||
|
||||
# Possible Problems:
|
||||
None
|
Loading…
Reference in New Issue
Block a user